| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update
|
To: |
Borislav Petkov <bp@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Xen Devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 |
|
From: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
|
Date: |
Wed, 02 Feb 2011 13:47:18 -0800 |
|
Cc: |
|
|
Delivery-date: |
Wed, 02 Feb 2011 13:48:35 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<20110202205704.GA14752@xxxxxxxxxxxx> |
|
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.1296259339.git.jeremy.fitzhardinge@xxxxxxxxxx> <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> <20110202205704.GA14752@xxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7 |
On 02/02/2011 12:57 PM, Borislav Petkov wrote:
> On Wed, Feb 02, 2011 at 11:52:22AM -0800, H. Peter Anvin wrote:
>> 3. Arguably on native hardware we should still load the microcode into
>> RAM in the boot loader, and install it on the very early CPU bringup
>> path. That means locking down some (currently) 400K of RAM to handle
>> different combinations of CPUs, or the additional complexity of
>> jettisoning microcode which cannot be used while still be able to deal
>> with hotplug. I think there is a strong case for this model, which
>> would mean moving the microcode into /boot anyway.
>
> /me like it, sounds very nifty. So how do we want to do that, we add
> a field to the real-mode kernel header that tells us where to find
> the microcode image and we take it and apply the ucode somewhere in
> do_boot_cpu() path?
>
We already have a mechanism for passing arbitrary blobs -- the linked
list -- so we don't have to add a new field at all.
-hpa
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home