WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0
From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
Date: Wed, 2 Feb 2011 22:55:17 -0200
Cc: Xen Devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>
Delivery-date: Wed, 02 Feb 2011 20:57:08 -0800
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=smtpout; bh=Mn4qSYE7MBZhsw87QK+srft5BeQ=; b=L746AuiQZmAaPsRow4jWcB66qRCW8rpehMDLgnG7BdLleYraMJcHweRcMYBf4Hakd9BvlSzJrXTMQqvBOirDPLMB0o8yH17zoxQaB3/LBQqO8aEJdA4Ktt3zz86WaEhsYHgKrcOYvgaEg/rdOvw0rbXDAnBL/+w+bTf+PY0Q6WA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D49B903.2080602@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110130113356.GA27967@xxxxxxxxxxxx> <4D461FB9.5050807@xxxxxxxx> <20110131070241.GA22071@xxxxxxxxxxxx> <4D46FC9F.6090309@xxxxxxxx> <20110131234131.GA16095@xxxxxxxxxxxx> <4D475099.1080004@xxxxxxxx> <4D475DB5.1020300@xxxxxxxxx> <4D488EB1.9020803@xxxxxxxx> <4D49B5F6.5010606@xxxxxxxxx> <4D49B903.2080602@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, 02 Feb 2011, Jeremy Fitzhardinge wrote:
> work with that.  That principally means getting the microcode images
> into /boot in a pre-digested form (binary, not text, and maybe pack the
> Intel and AMD files together in some extensible way - or at least give
> them self-describing headers).

I can get you a tool to manipulate the Intel microcode packs, and output
them in binary format.  I was planning to eventually switch Debian to it
anyway, as microcode.ctl is slow and unsuitable for initramfs use, and it is
high time we junked it.  The tool is somewhat messy, and I am pretty sure my
messy C is not going to get any good taste awards, but it works.

I will just remove support for /lib/firmware/intel-ucode/* from it before
making it public, because I want that hideously bad idea to DIE and it would
be counter-productive to actually create users for it (AFAIK, nobody ever
used /lib/firmware/intel-ucode/*, so we could still fix it).

But I'd really, really appreciate if someone from Intel [that actually cares
for operating system support of microcode updates] could vouch that we're
allowed to do that (convert their text packs to binary packs, merge
microcodes from older packs with the new to have a single pack with all
microcodes in their most up-to-date revision, and distribute the resulting
binary packs) before I make the tool public.

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.

> 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...

-- 
  "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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>