From: Borislav Petkov <bp@alien8.de>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Xen Devel <Xen-devel@lists.xensource.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0
Date: Sun, 30 Jan 2011 12:33:56 +0100 [thread overview]
Message-ID: <20110130113356.GA27967@liondog.tnic> (raw)
In-Reply-To: <cover.1296259339.git.jeremy.fitzhardinge@citrix.com>
On Fri, Jan 28, 2011 at 04:26:52PM -0800, Jeremy Fitzhardinge wrote:
> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>
> Hi all,
>
> I'm proposing this for 2.6.39.
>
> This series adds a new "Xen" microcode update type, in addition to
> Intel and AMD.
>
> The Xen hypervisor is responsible for performing the actual microcode
> update (since only it knows what physical CPUs are in the system and
> has sufficient privilege to access them), but it requires the dom0
> kernel to provide the actual microcode update data.
>
> Xen update mechanism is uniform independent of the CPU type, but the
> driver must know where to find the data file, which depends on the CPU
> type. And since the update hypercall updates all CPUs, we only need
> to execute it once on any CPU - but for simplicity it just runs it only
> on (V)CPU 0.
I don't like this for several reasons:
- ucode should be loaded as early as possible and the perfect place
for that should be the hypervisor and not the dom0 kernel. But I'm not
that familiar with xen design and I guess it would be pretty hard to
do. (Btw, x86 bare metal could also try to improve the situation there
but that's also hard due to the design of the firmware loader (needs
userspace)).
- you're adding a microcode_xen.c as if this is another hw vendor and
you're figuring out which is the proper firmware image based on the
vendor, then you load it and then do the hypercall. This is duplicating
code and inviting future bugs. Everytime the hw vendors decide to change
something to their fw loading mechanism, xen needs to be updated. Also,
you don't do any sanity checks to the ucode image as the vendor code
does which is inacceptable.
What it should do instead, is call into the hw vendor-specific ucode
loading mechanism and do all the image loading/verification there. The
only thing you'd need to supply is a xen-specific ->apply_microcode()
doing the hypercall _after_ the ucode image has been verified and is
good to go. I'm guessing the XENPF_microcode_update does call into the
hypervisor and calls a xen-specific ucode update mechanism based on the
vendor instead of using the vendor-supplied code...
Thanks.
--
Regards/Gruss,
Boris.
next prev parent reply other threads:[~2011-01-30 11:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-29 0:26 Jeremy Fitzhardinge
[not found] ` <cover.1296260656.git.jeremy.fitzhardinge@citrix.com>
2011-01-29 0:26 ` [PATCH 1/2] xen dom0: Add support for the platform_ops hypercall Jeremy Fitzhardinge
2011-01-29 0:26 ` [PATCH 2/2] xen: add CPU microcode update driver Jeremy Fitzhardinge
2011-01-30 11:33 ` Borislav Petkov [this message]
2011-01-31 2:34 ` [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 Jeremy Fitzhardinge
2011-01-31 7:02 ` Borislav Petkov
2011-01-31 18:17 ` Jeremy Fitzhardinge
2011-01-31 23:41 ` Borislav Petkov
2011-02-01 0:15 ` Jeremy Fitzhardinge
2011-02-01 1:11 ` H. Peter Anvin
2011-02-01 22:52 ` Jeremy Fitzhardinge
2011-02-02 19:52 ` H. Peter Anvin
2011-02-02 20:05 ` Jeremy Fitzhardinge
2011-02-02 20:34 ` Thomas Gleixner
2011-02-03 0:55 ` Henrique de Moraes Holschuh
2011-02-03 0:58 ` H. Peter Anvin
2011-02-03 7:47 ` Borislav Petkov
2011-02-03 16:05 ` Henrique de Moraes Holschuh
2011-02-02 20:57 ` Borislav Petkov
2011-02-02 21:47 ` H. Peter Anvin
2011-02-03 18:25 ` Borislav Petkov
2011-02-03 18:33 ` H. Peter Anvin
2011-02-01 11:00 ` Borislav Petkov
2011-02-01 23:12 ` Jeremy Fitzhardinge
2011-02-02 9:54 ` Borislav Petkov
2011-02-02 12:48 ` Henrique de Moraes Holschuh
2011-02-02 18:05 ` Jeremy Fitzhardinge
2011-02-02 18:29 ` Jeremy Fitzhardinge
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=20110130113356.GA27967@liondog.tnic \
--to=bp@alien8.de \
--cc=Xen-devel@lists.xensource.com \
--cc=hpa@zytor.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®