All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xen.org
Subject: Re: [RFC PATCH v1] microcode: Scan the initramfs payload for microcode blob.
Date: Mon, 15 Jul 2013 10:36:27 -0400	[thread overview]
Message-ID: <20130715143627.GB4817@phenom.dumpdata.com> (raw)
In-Reply-To: <51E3BF7802000078000E4D19@nat28.tlf.novell.com>

On Mon, Jul 15, 2013 at 08:23:04AM +0100, Jan Beulich wrote:
> >>> On 12.07.13 at 16:25, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -760,6 +760,18 @@ only available on 32-bit x86 platforms.
> >  
> >  `acpi` instructs Xen to reboot the host using RESET_REG in the ACPI FADT.
> >  
> > +### scan_ucode
> > +> `= <boolean>`
> > +
> > +> Default: `true`
> > +
> > +Flag to globally enable or disable support for scanning the multiboot images
> > +for an cpio image that contains microcode, which are:
> > + on Intel: kernel/x86/microcode/GenuineIntel.bin
> > + on AMD  : kernel/x86/microcode/AuthenticAMD.bin
> > +
> > +Note that is 'ucode' parameter is used this option becomes disabled.
> > +
> 
> I would want this to be an extension of the "ucode=" option, not
> an independent new one. E.g. "ucode=initrd" or
> "ucode=cpio:<num>" or some such.

I believe that it would be best suited for users if said feature was
turned on by default - and then if needed - can be turned off. Similarly
to how HAP is enabled by default.

Using the over-ride in 'ucode' parse code is fine with me. I would propose
'ucode=noscan' or 'ucode=noauto' as the parameters.
> 
> > --- a/xen/arch/x86/microcode.c
> > +++ b/xen/arch/x86/microcode.c
> > @@ -39,12 +39,33 @@
> >  #include <asm/setup.h>
> >  #include <asm/microcode.h>
> >  
> > +#include <xen/earlycpio.h>
> > +
> >  static module_t __initdata ucode_mod;
> >  static void *(*__initdata ucode_mod_map)(const module_t *);
> >  static signed int __initdata ucode_mod_idx;
> >  static bool_t __initdata ucode_mod_forced;
> >  static cpumask_t __initdata init_mask;
> >  
> > +/*
> > + * If we scan the initramfs.cpio for the early microcode code
> > + * and find it, then 'ucode_blob' will contain the pointer
> > + * and the size of said blob. It is allocated from Xen's heap
> > + * memory.
> > + */
> > +struct ucode_mod_blob {
> > +    void *data;
> > +    size_t size;
> > +};
> > +
> > +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.

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.

> 
> Reviewing the rest of the patch requires clarification on the
> concept first, as asked for in response to the "overview" mail.
> 
> Jan
> 
> 

  reply	other threads:[~2013-07-15 14:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-12 14:25 [RFC PATCH] Scan initramfs for microcode cpio archive. (v1) Konrad Rzeszutek Wilk
2013-07-12 14:25 ` [RFC PATCH v1] microcode: Scan the initramfs payload for microcode blob Konrad Rzeszutek Wilk
2013-07-15  7:23   ` Jan Beulich
2013-07-15 14:36     ` Konrad Rzeszutek Wilk [this message]
2013-07-15 14:52       ` Jan Beulich
2013-07-15  7:18 ` [RFC PATCH] Scan initramfs for microcode cpio archive. (v1) Jan Beulich
2013-07-15 12:31   ` David Vrabel
2013-07-15 14:34   ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130715143627.GB4817@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=konrad@kernel.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.