Date: Thu, 12 Jul 2018 18:46:31 -0400 From: Mark Johnston <markj@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180712224631.GF15892@raichu> In-Reply-To: <50839.1531428749@critter.freebsd.dk> References: <20180712183116.GB15892@raichu> <50839.1531428749@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 12, 2018 at 08:52:29PM +0000, Poul-Henning Kamp wrote:
> --------
> In message <20180712183116.GB15892@raichu>, Mark Johnston writes:
>
> >My plan is to extend cpucontrol(8) to determine the
> >correct microcode update for the running system, and have the devcpu-data
> >port install the corresponding file to /boot/firmware.
>
> This is problematic when a diskimage is migrated to a different CPU,
> only on the second reboot on the new hardware are you certain to
> have the correct microcode.
>
> For images which are resurrected on demand on whatever hardware is
> available this really problematic.
I can think of three ways to address this case:
1a) Always load all of the updates as a single file, and select the
correct update during boot. As I pointed out, this wastes some
memory (a couple of megabytes currently). On at least amd64 it
doesn't look very practical to release the pages backing the
update file back to the VM. That is, I don't think we can easily
"shed" the preloaded file data once the correct update has been
selected and saved.
1b) Have the devcpu-data port operate in one of two modes: either the
port selects the update for the current machine, as I outlined in my
original mail, or it concatenates all of the updates as in 1a) and
the kernel selects the correct update. This way we'd only
waste memory if the disk image is to be shared among multiple
machines. I'm not sure what the mechanism should be for selecting
the mode.
2) Install all updates to a directory under /boot and add code to the
loader to perform the selection, and pass only the required microcode
file to the kernel. This seems straightforward to me, though I'm not
yet sure exactly where in the loader this logic should go.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180712224631.GF15892>