x86/ucode: add support for early loading of CPU ucode on AMD.

Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D43318

x86/ucode: add const where appropriate

Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D43865

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

Free microcode memory later.

With lockless DI, pmap_remove() requires operational thread lock,
which is initialized at SI_SUB_RUN_QUEUE for thread0. Move it even
later where APs are started, the moment after which other boot memory
like trampoline stacks is already being freed.

Reported by: gtetlow
Sponsored by: The FreeBSD Foundation
MFC after: 30 days

Fix the PAE kernel gcc build.

The error was caused by map_ucode() casting a vm_paddr_t to a void *.
Use a uintptr_t instead to match the caller. Fix some style bugs while
here.

Reported by: bde
Reviewed by: bde
MFC after: 1 week
Sponsored by: The FreeBSD Foundation

Provide string functions for use before ifuncs get resolved.

The change is a no-op for architectures which don't ifunc memset,
memcpy nor memmove.

Convert places which need them. Xen bits by royger.

Reviewed by: kib
Approved by: re (gjb)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17487

Fix an inverted test in ucode_load_ap().

This caused microcode to be updated only on the BSP if hyperthreading
was disabled, typically resulting in a hang or reset.

Approved by: re (kib)
Sponsored by: The FreeBSD Foundation

Log a message after a successful boot-time microcode update.

Reviewed by: kib
Approved by: re (delphij)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17135

Help ensure that the copy loop doesn't get converted to a memcpy() call.

Reported and reviewed by: kib
X-MFC with: r337715
Sponsored by: The FreeBSD Foundation

Explain why we aren't using memcpy().

Reported by: jmg
X-MFC with: r337715
Sponsored by: The FreeBSD Foundation

Don't use memcpy() in the early microcode loading code.

At some point memcpy() may be an ifunc, ifunc resolution cannot be done
until CPU identification has been performed, and CPU identification must
be done after loading any microcode updates.

X-MFC with: r337715
Sponsored by: The FreeBSD Foundation

Fix the !SMP x86 build.

Reported by: Michael Butler <imb@protected-networks.net>
X-MFC with: r337715
Sponsored by: The FreeBSD Foundation

Implement kernel support for early loading of Intel microcode updates.

Updates in the format described in section 9.11 of the Intel SDM can
now be applied as one of the first steps in booting the kernel. Updates
that are loaded this way are automatically re-applied upon exit from
ACPI sleep states, in contrast with the existing cpucontrol(8)-based
method. For the time being only Intel updates are supported.

Microcode update files are passed to the kernel via loader(8). The
file type must be "cpu_microcode" in order for the file to be recognized
as a candidate microcode update. Updates for multiple CPU types may be
concatenated together into a single file, in which case the kernel
will select and apply a matching update. Memory used to store the
update file will be freed back to the system once the update is applied,
so this approach will not consume more memory than required.

Reviewed by: kib
MFC after: 6 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16370