xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Benjamin.Guthro@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	stefan.bader@canonical.com, xen-devel <xen-devel@lists.xen.org>,
	david.vrabel@citrix.com
Subject: Re: Linux 3.11 and the future...
Date: Fri, 7 Jun 2013 06:58:45 -0700 (PDT)	[thread overview]
Message-ID: <20130607135845.GG25649@phenom.dumpdata.com> (raw)
In-Reply-To: <51B0A76502000078000DBE29@nat28.tlf.novell.com>

On Thu, Jun 06, 2013 at 02:14:45PM +0100, Jan Beulich wrote:
> >>> On 06.06.13 at 15:07, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Jun 06, 2013 at 08:38:57AM +0100, Jan Beulich wrote:
> >> >>> On 05.06.13 at 22:19, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> >  b) microcode update. One needs to cherry-pick
> >> >     xen: add CPU microcode update driver
> >> >     x86/microcode: check proper return code.
> >> >     microcode_xen: Add support for AMD family >= 15h
> >> > 
> >> >    The one solution is to use the piggyback on early microcode loading
> >> >    that the Linux kernel is doing. Needs implementation in the hypervisor.
> >> 
> >> What hypervisor side solution apart from the existing ucode
> >> updating during early boot are you thinking of here?
> > 
> > Copy from the
> > http://wiki.xen.org/wiki/GSoC_2013#Microcode_uploader_implementation_in_Xen_ 
> > hypervisor
> > 
> > "
> > Intel is working on early implementation where the microcode binary
> > would be appended to the initrd image. The kernel would scan for the
> > appropriate magic constant
> > (http://thread.gmane.org/gmane.linux.kernel/1413384; looks for
> > "kernel/x86/microcode/GenuineIntel.bin") and load the microcode very
> > early. This is all done for the Linux kernel code, but we currently do
> > not that in the Xen hypervisor.
> > The scope of the work can be split up in
> > a) just do the extraction of microcode from the initial ramdisk binary (aka
> > initrd) and apply it. This can be done during the parsing of the dom0
> > initial ramdisk. The hypervisor already has the functionality to apply a
> > microcode from the multiboot targets. This would add code to parse the
> > initrd image
> > b) do it during very early bootup - which is why the early microcode work
> > started - to deal with CPUs which don't expose certain CPUID flags
> > because they need a microcode update. This part of work is much more
> > difficult - as it would involve working only with early bootup
> > pagetables. This being done _before_ the Xen hypervisor sets its own
> > pagetables - as some of the fixes that the microcode has, can be for the
> > CPU to be able to do PSE properly.
> > "
> > 
> > The a) solution was what I had in mind.
> 
> Imo this is not a viable option - we shouldn't start peeking into the
> second module (which Linux uses as initrd, but which other OSes
> may use for other purposes) - so far this is just a binary blob to the
> hypervisor.
> 

I was under the impression that the code you introduced for microcode loading
was doing that exactly. Granted it would only peek if told to. Perhaps that
code can be expanded to scan the blob for cpio image of microcode in whatever
it was told to look at?

Dracut could pass in the extra argument to hypervisor to tell it to scan
the initrd image.

> Jan
> 

  reply	other threads:[~2013-06-07 13:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-05 20:19 Linux 3.11 and the future Konrad Rzeszutek Wilk
2013-06-06  7:38 ` Jan Beulich
2013-06-06 13:07   ` Konrad Rzeszutek Wilk
2013-06-06 13:14     ` Jan Beulich
2013-06-07 13:58       ` Konrad Rzeszutek Wilk [this message]
2013-06-07 15:43         ` Jan Beulich
2013-06-07 17:03           ` 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=20130607135845.GG25649@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=Benjamin.Guthro@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=stefan.bader@canonical.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).