Re: [Xen-devel] [RFC PATCH v1] microcode: Scan the initramfs payload for microcode blob.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.07.13 at 16:36, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Mon, Jul 15, 2013 at 08:23:04AM +0100, Jan Beulich wrote:
>> >>> On 12.07.13 at 16:25, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
>> > +static struct ucode_mod_blob __initdata ucode_blob;
>> > +/*
>> > + * By default we will parse the multiboot modules to see if there is
>> > + * cpio image with the microcode images.
>> > + */
>> > +static bool_t __initdata opt_scan_ucode = 1;
>> > +boolean_param("scan_ucode", opt_scan_ucode);
>> 
>> I'm also unsure we really want this on by default. "ucode=<num>"
>> also isn't having any "default on" effect.
> 
> Correct. Because it ('ucode=<num>') is unable to figure out which of
> the multiboot payloads has the ucode. It needs the help from GRUB2
> or other tools that construct the bootloader configuration files.

No - it could have been coded the same way as XSM. But when
I put this together, the approach of looking just at the first few
bytes and draw conclusions from that seemed to fragile to me.
Admitted XSM at least has some kind signature there, but at least
AMD ucode has too, so one could have used that. Still I think
that having the user explicitly state what (s)he wants is better
than this guesswork.

> This code, similar to how XSM finds its policy, can find the microcode
> blob without the help of the bootloader.
> 
> In the Linux code if this feature is turned on it will _always_
> search the initramfs. I think that idea makes sense here as well -
> we want to enable X feature if we detect that it exists.

Linux can safely always do that, because it can make assumptions
about the format of the initrd. Xen otoh has to be careful not to
mis-interpret a blob passed to a non-Linux Dom0 as a CPIO. How
good the guarding against this is in the code I'll have to check
(now that the question regarding the concatenation was
answered By David).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel