|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH 0/3] x86/microcode: support for microcode update
To: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH 0/3] x86/microcode: support for microcode update in Xen dom0 |
From: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
Date: |
Wed, 12 Oct 2011 13:22:41 -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 13:25:58 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4E95E7FE.6050302@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: |
<cover.1317060617.git.jeremy.fitzhardinge@xxxxxxxxxx> <4E94E1E5.4070505@xxxxxxxx> <20111012101615.GA14966@aftab> <4E95D9E7.6090304@xxxxxxxxx> <4E95E7FE.6050302@xxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
On 10/12/2011 12:18 PM, Jeremy Fitzhardinge wrote:
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.
It *is* how we want to do microcode in the future. There is a prototype
for the Intel hardware side here; we just haven't had time to finalize
it partly because I got pulled onto the kernel.org situation.
But for right now, this patch seems like the pragmatic solution.
No.
I think the real question is where there's something objectionable about
the patch itself?
"It does something that is slightly broken on real hardware and totally
broken for a hypervisor and perpetuates it, while still needing enabling?"
-hpa
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|