| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH 0/3] x86/microcode: support for microcode update
|
To: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [PATCH 0/3] x86/microcode: support for microcode update in Xen dom0 |
|
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Date: |
Wed, 12 Oct 2011 12:18:22 -0700 |
|
Cc: |
Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Tigran Aivazian <tigran@xxxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx> |
|
Delivery-date: |
Wed, 12 Oct 2011 12:19:20 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4E95D9E7.6090304@xxxxxxxxx> |
|
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: |
<cover.1317060617.git.jeremy.fitzhardinge@xxxxxxxxxx> <4E94E1E5.4070505@xxxxxxxx> <20111012101615.GA14966@aftab> <4E95D9E7.6090304@xxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 |
On 10/12/2011 11:18 AM, H. Peter Anvin wrote:
> On 10/12/2011 03:16 AM, Borislav Petkov wrote:
>> Why would a xen microcode solution would even be contingent on how
>> upstream Linux solves it (and when)?
>>
> Agreed... especially since Xen is "special" when it comes to booting anyway.
"Special" only in the sense that you need a new line in grub.
But doing boot-time microcode is a lot more "special" since it would
require distros to move the microcode files to /boot. That would either
mean having two sets of microcode packages, or also changing the way
that Linux does its microcode loading (if only by changing the paths,
but I have no idea what that implies since its all tied up with the rest
of the firmware loading stuff).
The whole thrust of the Xen upstreaming work has been to minimize the
amount of arbitrary "specialness" so that its as easy as possibly for
people and distros to deploy and use Xen.
With respect to microcode loading, this patch means that users and
distros just don't need to worry about microcode any more. It packages
and operates exactly like it would for native Linux, which is exactly
how we like it.
While doing the whole boot time multiboot thing may offer some small
hypothetical technical advantages, it has the significant cost of just
complicating the whole deployment and use story.
If there were a general shift to "this is how we're going to do
microcode in the future", then Xen will happily go along for the ride.
But for right now, this patch seems like the pragmatic solution.
I think the real question is where there's something objectionable about
the patch itself?
Thanks,
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home