[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time (pre-Dom0) loading



>>> On 30.11.11 at 23:23, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
> On Wed, Nov 30, 2011 at 04:27:11PM +0000, Jan Beulich wrote:
>> Largely as a result of the continuing resistance of Linux maintainers
>> to accept a microcode loading patch for pv-ops Xen kernels, this
>> follows the suggested route and provides a means to load microcode
>> updates without the assistance of Dom0, thus also addressing eventual
>> problems in the hardware much earlier.
>> 
>> This leverages the fact that via the multiboot protocol another blob
>> of data can be easily added in the form of just an extra module. Since
>> microcode data cannot reliably be recognized by looking at the
>> provided data, this requires (in the non-EFI case) the use of a
>> command line parameter ("ucode=<number>") to identify which of the
> 
> Well, usually there would be two modules - the kernel (which we can
> identify) and the initramfs (which I guess one can also identify)?
> It seems that by process of elimination we could determine that the
> remaining module is the blob? Or would that be simple too dangerous
> to make such assumption?

For one, we must not imply that what Linux calls "initrd" isn't used as
something completely different on other possible Dom0 OSes. Hence
we can't make assumptions on the format of this module.

And second, yes, I consider it too dangerous to guess on what might
be the microcode blob.

>> modules is to be parsed for an eventual microcode update (in the EFI
>> case the module is being identified in the config file, and hence the
>> command line argument, if given, will be ignored).
>> 
>> This required to adjust the XSM module determination logic accordingly.
>> 
>> The format of the data to be provided is the raw binary blob already
>> used for AMD CPUs, and the output of the intel-microcode2ucode utility
>> for the Intel case (either the per-(family,model,stepping) file or -
>> to make things easier for distro-s integration-wise - simply the
>> concatenation of all of them).
> 
> There was some talk by hpa and borislav of how they wanted the payload,
> but it never got finalized I think? Would it make sense to CC them on
> this to see how they are planning to implement it in GRUB2?

Adding them to Cc now.

> I got the impression they wanted some new .pack format or so?
> Or is the format that they were talking about exactly what you picked?

I merely picked the binary formats that are already in use; I see no
reason to invent another one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.