mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Borislav Petkov <bp@amd64.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
	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>,
	Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0
Date: Thu, 3 Feb 2011 14:05:21 -0200	[thread overview]
Message-ID: <20110203160521.GA29349@khazad-dum.debian.net> (raw)
In-Reply-To: <20110203074758.GA23561@aftab>

On Thu, 03 Feb 2011, Borislav Petkov wrote:
> On Wed, Feb 02, 2011 at 10:55:17PM -0200, Henrique de Moraes Holschuh wrote:
> > It would not be much of a problem to add AMD support to it as well (or write
> > a separate tool), just point me to a friendly AMD engineer that will supply
> > the docs (or point me to them if they're already public), vouch for the fact
> > that we're allowed to unpack/merge/strip/repack AMD microcode packs, and
> > test the tool, because I have no AMD boxes at home or at work to test it.
> 
> We already have a single container file with all the ucode patches in
> it: http://www.amd64.org/support/microcode.html and the microcode driver
> in the kernel can look at it and take out the patches it needs based on
> the CPU it is running on. Is that what you had in mind?

Validate the container file in userspace, let the user list available
microcode updates, let the user merge multiple container files into a new
one with just the most up-to-date microcodes for each CPU, optionally
filtered for the CPUs currently online, or to the ones specificed in the
command line.

I have a tool that does that for Intel, based on their documentation and
also on the Linux driver.

However, since AMD has so few microcodes in that file and it is so small,
that's probably not useful at all right now.  Maybe in a few years :-)

> > > My main concern is that I want Xen to Just Work - ideally by not
> > > requiring users/admins to do anything.
> > 
> > I have no experience with Xen.  What do I get from cpuid(0) and cpuid(1) in
> > dom0 when the bare metal uses Intel CPUs?  And AMD CPUs?   I'd like to teach
> > the tool to not do anything idiotic under Xen...
> 
> Actually, if the microcode image can be provided to the hypervisor early
> using multiboot, it should be easy for it to figure out on what hardware
> it is running and apply the correct microcode without the need for dom0
> to know anything about microcode, IMHO.

I'd still appreciate that information.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  reply	other threads:[~2011-02-03 16:05 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 ` [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 Borislav Petkov
2011-01-31  2:34   ` 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 [this message]
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=20110203160521.GA29349@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=Xen-devel@lists.xensource.com \
    --cc=bp@alien8.de \
    --cc=bp@amd64.org \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=keir.fraser@eu.citrix.com \
    --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®