On 01/31/2011 05:11 PM, H. Peter Anvin wrote:
> Note: Xen may not have devices, but it is already using multiboot to
> load multiple modules. It could load the microcode blob that way.
>
> That would enable an earlier loading of microcode, which is a very
> good thing.
Yes, that is a thought, but it would require some distro support to make
sure the firmware is copied into /boot, and grub updated appropriately.
The principle advantage of updating the microcode driver is that it Just
Works regardless of whether the system is booting native or Xen.
J
On 02/01/2011 02:52 PM, Jeremy Fitzhardinge wrote:
> On 01/31/2011 05:11 PM, H. Peter Anvin wrote:
>> Note: Xen may not have devices, but it is already using multiboot to
>> load multiple modules. It could load the microcode blob that way.
>>
>> That would enable an earlier loading of microcode, which is a very
>> good thing.
>
> Yes, that is a thought, but it would require some distro support to make
> sure the firmware is copied into /boot, and grub updated appropriately.
>
> The principle advantage of updating the microcode driver is that it Just
> Works regardless of whether the system is booting native or Xen.
>
As I mentioned on IRC...
1. Xen already uses Multiboot, so it's a fairly trivial thing to add
another item to the list for the boot loader to get.
2. The only reason we don't currently install microcode from the boot
loader is because of the considerable complexity in adding SMP support
to boot loaders, as it requires handling the APIC system.
3. Arguably on native hardware we should still load the microcode into
RAM in the boot loader, and install it on the very early CPU bringup
path. That means locking down some (currently) 400K of RAM to handle
different combinations of CPUs, or the additional complexity of
jettisoning microcode which cannot be used while still be able to deal
with hotplug. I think there is a strong case for this model, which
would mean moving the microcode into /boot anyway.
-hpa
On 02/02/2011 11:52 AM, H. Peter Anvin wrote:
> As I mentioned on IRC...
>
> 1. Xen already uses Multiboot, so it's a fairly trivial thing to add
> another item to the list for the boot loader to get.
>
> 2. The only reason we don't currently install microcode from the boot
> loader is because of the considerable complexity in adding SMP support
> to boot loaders, as it requires handling the APIC system.
>
> 3. Arguably on native hardware we should still load the microcode into
> RAM in the boot loader, and install it on the very early CPU bringup
> path. That means locking down some (currently) 400K of RAM to handle
> different combinations of CPUs, or the additional complexity of
> jettisoning microcode which cannot be used while still be able to deal
> with hotplug. I think there is a strong case for this model, which
> would mean moving the microcode into /boot anyway.
If we can come up with a scheme that works for both native and Xen (or
at least v. similar) that we can get distros to support, then we can
work with that. That principally means getting the microcode images
into /boot in a pre-digested form (binary, not text, and maybe pack the
Intel and AMD files together in some extensible way - or at least give
them self-describing headers).
But in the meantime it would be nice to have microcode updates under Xen
within the existing model (or failing that, a little patch to prevent
the spew of spurious errors when the kernel tries and fails - but it
would be strongly preferable to actually update microcode).
My main concern is that I want Xen to Just Work - ideally by not
requiring users/admins to do anything.
J
On Wed, 2 Feb 2011, Jeremy Fitzhardinge wrote:
> On 02/02/2011 11:52 AM, H. Peter Anvin wrote:
> > As I mentioned on IRC...
> >
> > 1. Xen already uses Multiboot, so it's a fairly trivial thing to add
> > another item to the list for the boot loader to get.
> >
> > 2. The only reason we don't currently install microcode from the boot
> > loader is because of the considerable complexity in adding SMP support
> > to boot loaders, as it requires handling the APIC system.
> >
> > 3. Arguably on native hardware we should still load the microcode into
> > RAM in the boot loader, and install it on the very early CPU bringup
> > path. That means locking down some (currently) 400K of RAM to handle
> > different combinations of CPUs, or the additional complexity of
> > jettisoning microcode which cannot be used while still be able to deal
> > with hotplug. I think there is a strong case for this model, which
> > would mean moving the microcode into /boot anyway.
>
> If we can come up with a scheme that works for both native and Xen (or
> at least v. similar) that we can get distros to support, then we can
> work with that. That principally means getting the microcode images
> into /boot in a pre-digested form (binary, not text, and maybe pack the
> Intel and AMD files together in some extensible way - or at least give
> them self-describing headers).
>
> But in the meantime it would be nice to have microcode updates under Xen
> within the existing model (or failing that, a little patch to prevent
> the spew of spurious errors when the kernel tries and fails - but it
> would be strongly preferable to actually update microcode).
>
> My main concern is that I want Xen to Just Work - ideally by not
> requiring users/admins to do anything.
Well, that's a noble goal, but the reality is that Xen is not even
close to the point where it Just Works. So instead of slapping some
weird workaround into the kernel, we really should go for the correct
solution right away.
Thanks,
tglx
On Wed, Feb 02, 2011 at 11:52:22AM -0800, H. Peter Anvin wrote:
> 3. Arguably on native hardware we should still load the microcode into
> RAM in the boot loader, and install it on the very early CPU bringup
> path. That means locking down some (currently) 400K of RAM to handle
> different combinations of CPUs, or the additional complexity of
> jettisoning microcode which cannot be used while still be able to deal
> with hotplug. I think there is a strong case for this model, which
> would mean moving the microcode into /boot anyway.
/me like it, sounds very nifty. So how do we want to do that, we add
a field to the real-mode kernel header that tells us where to find
the microcode image and we take it and apply the ucode somewhere in
do_boot_cpu() path?
--
Regards/Gruss,
Boris.
On 02/02/2011 12:57 PM, Borislav Petkov wrote:
> On Wed, Feb 02, 2011 at 11:52:22AM -0800, H. Peter Anvin wrote:
>> 3. Arguably on native hardware we should still load the microcode into
>> RAM in the boot loader, and install it on the very early CPU bringup
>> path. That means locking down some (currently) 400K of RAM to handle
>> different combinations of CPUs, or the additional complexity of
>> jettisoning microcode which cannot be used while still be able to deal
>> with hotplug. I think there is a strong case for this model, which
>> would mean moving the microcode into /boot anyway.
>
> /me like it, sounds very nifty. So how do we want to do that, we add
> a field to the real-mode kernel header that tells us where to find
> the microcode image and we take it and apply the ucode somewhere in
> do_boot_cpu() path?
>
We already have a mechanism for passing arbitrary blobs -- the linked
list -- so we don't have to add a new field at all.
-hpa
On Wed, 02 Feb 2011, Jeremy Fitzhardinge wrote:
> work with that. That principally means getting the microcode images
> into /boot in a pre-digested form (binary, not text, and maybe pack the
> Intel and AMD files together in some extensible way - or at least give
> them self-describing headers).
I can get you a tool to manipulate the Intel microcode packs, and output
them in binary format. I was planning to eventually switch Debian to it
anyway, as microcode.ctl is slow and unsuitable for initramfs use, and it is
high time we junked it. The tool is somewhat messy, and I am pretty sure my
messy C is not going to get any good taste awards, but it works.
I will just remove support for /lib/firmware/intel-ucode/* from it before
making it public, because I want that hideously bad idea to DIE and it would
be counter-productive to actually create users for it (AFAIK, nobody ever
used /lib/firmware/intel-ucode/*, so we could still fix it).
But I'd really, really appreciate if someone from Intel [that actually cares
for operating system support of microcode updates] could vouch that we're
allowed to do that (convert their text packs to binary packs, merge
microcodes from older packs with the new to have a single pack with all
microcodes in their most up-to-date revision, and distribute the resulting
binary packs) before I make the tool public.
It would not be much of a problem to add AMD support to it as well (or write
a separate tool), just point me to a friendly AMD engineer that will supply
the docs (or point me to them if they're already public), vouch for the fact
that we're allowed to unpack/merge/strip/repack AMD microcode packs, and
test the tool, because I have no AMD boxes at home or at work to test it.
> My main concern is that I want Xen to Just Work - ideally by not
> requiring users/admins to do anything.
I have no experience with Xen. What do I get from cpuid(0) and cpuid(1) in
dom0 when the bare metal uses Intel CPUs? And AMD CPUs? I'd like to teach
the tool to not do anything idiotic under Xen...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On 02/02/2011 04:55 PM, Henrique de Moraes Holschuh wrote:
>
> But I'd really, really appreciate if someone from Intel [that actually cares
> for operating system support of microcode updates] could vouch that we're
> allowed to do that (convert their text packs to binary packs, merge
> microcodes from older packs with the new to have a single pack with all
> microcodes in their most up-to-date revision, and distribute the resulting
> binary packs) before I make the tool public.
>
I'm trying to figure this stuff out already.
The actual conversion isn't a problem, obviously.
-hpa
On Wed, Feb 02, 2011 at 10:55:17PM -0200, Henrique de Moraes Holschuh wrote:
> It would not be much of a problem to add AMD support to it as well (or write
> a separate tool), just point me to a friendly AMD engineer that will supply
> the docs (or point me to them if they're already public), vouch for the fact
> that we're allowed to unpack/merge/strip/repack AMD microcode packs, and
> test the tool, because I have no AMD boxes at home or at work to test it.
We already have a single container file with all the ucode patches in
it: http://www.amd64.org/support/microcode.html and the microcode driver
in the kernel can look at it and take out the patches it needs based on
the CPU it is running on. Is that what you had in mind?
> > My main concern is that I want Xen to Just Work - ideally by not
> > requiring users/admins to do anything.
>
> I have no experience with Xen. What do I get from cpuid(0) and cpuid(1) in
> dom0 when the bare metal uses Intel CPUs? And AMD CPUs? I'd like to teach
> the tool to not do anything idiotic under Xen...
Actually, if the microcode image can be provided to the hypervisor early
using multiboot, it should be easy for it to figure out on what hardware
it is running and apply the correct microcode without the need for dom0
to know anything about microcode, IMHO.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
On Thu, 03 Feb 2011, Borislav Petkov wrote:
> On Wed, Feb 02, 2011 at 10:55:17PM -0200, Henrique de Moraes Holschuh wrote:
> > It would not be much of a problem to add AMD support to it as well (or write
> > a separate tool), just point me to a friendly AMD engineer that will supply
> > the docs (or point me to them if they're already public), vouch for the fact
> > that we're allowed to unpack/merge/strip/repack AMD microcode packs, and
> > test the tool, because I have no AMD boxes at home or at work to test it.
>
> We already have a single container file with all the ucode patches in
> it: http://www.amd64.org/support/microcode.html and the microcode driver
> in the kernel can look at it and take out the patches it needs based on
> the CPU it is running on. Is that what you had in mind?
Validate the container file in userspace, let the user list available
microcode updates, let the user merge multiple container files into a new
one with just the most up-to-date microcodes for each CPU, optionally
filtered for the CPUs currently online, or to the ones specificed in the
command line.
I have a tool that does that for Intel, based on their documentation and
also on the Linux driver.
However, since AMD has so few microcodes in that file and it is so small,
that's probably not useful at all right now. Maybe in a few years :-)
> > > My main concern is that I want Xen to Just Work - ideally by not
> > > requiring users/admins to do anything.
> >
> > I have no experience with Xen. What do I get from cpuid(0) and cpuid(1) in
> > dom0 when the bare metal uses Intel CPUs? And AMD CPUs? I'd like to teach
> > the tool to not do anything idiotic under Xen...
>
> Actually, if the microcode image can be provided to the hypervisor early
> using multiboot, it should be easy for it to figure out on what hardware
> it is running and apply the correct microcode without the need for dom0
> to know anything about microcode, IMHO.
I'd still appreciate that information.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Wed, Feb 02, 2011 at 01:47:18PM -0800, H. Peter Anvin wrote:
> On 02/02/2011 12:57 PM, Borislav Petkov wrote:
> > On Wed, Feb 02, 2011 at 11:52:22AM -0800, H. Peter Anvin wrote:
> >> 3. Arguably on native hardware we should still load the microcode into
> >> RAM in the boot loader, and install it on the very early CPU bringup
> >> path. That means locking down some (currently) 400K of RAM to handle
> >> different combinations of CPUs, or the additional complexity of
> >> jettisoning microcode which cannot be used while still be able to deal
> >> with hotplug. I think there is a strong case for this model, which
> >> would mean moving the microcode into /boot anyway.
> >
> > /me like it, sounds very nifty. So how do we want to do that, we add
> > a field to the real-mode kernel header that tells us where to find
> > the microcode image and we take it and apply the ucode somewhere in
> > do_boot_cpu() path?
> >
>
> We already have a mechanism for passing arbitrary blobs -- the linked
> list -- so we don't have to add a new field at all.
So, after staring at grub legacy sources a bit, we could load the
microcode image using the grub module's mechanism:
kernel /...
module /boot/microcode.gz type=SETUP_MICROCODE # this is looked at by parse_setup_data()
and let grub write the pointer into setup_data passed through the kernel
header.
This would mean that we need to add support to a bunch of boot loaders
used currently, no? Or is there an even better way?
--
Regards/Gruss,
Boris.
On 02/03/2011 10:25 AM, Borislav Petkov wrote:
>>
>> We already have a mechanism for passing arbitrary blobs -- the linked
>> list -- so we don't have to add a new field at all.
>
> So, after staring at grub legacy sources a bit, we could load the
> microcode image using the grub module's mechanism:
>
> kernel /...
> module /boot/microcode.gz type=SETUP_MICROCODE # this is looked at by parse_setup_data()
>
> and let grub write the pointer into setup_data passed through the kernel
> header.
>
> This would mean that we need to add support to a bunch of boot loaders
> used currently, no? Or is there an even better way?
>
We would need to add boot loader support, yes.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.