|
xen-devel
[Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update
|
To: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [PATCH 0/2] x86/microcode: support for microcode update in Xen dom0 |
|
From: |
Borislav Petkov <bp@xxxxxxxxx> |
|
Date: |
Thu, 3 Feb 2011 19:25:50 +0100 |
|
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen Devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx> |
|
Delivery-date: |
Thu, 03 Feb 2011 10:26:39 -0800 |
|
Dkim-signature: |
v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1296757552; bh=iHfFeRdxYKuQ6yE0RYW6x0cHqap84dHP3SjcGJ+xQDc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=ircgQbl7EFoNSCWRXPtNaDlOET+CH1atv3rP3g Mwgh9V3zaNeZoJlmok7EB34PRtEOtEViZ3XQq97iDBtG3Tr4N8XZ0fF98IlgWNseJK4 0jeCG4QqhAF3fa2DQnME3Ko55vyB91iq9/OQM5J/t5wDiOD0+1Wah5UoyMm07c561w= |
|
Dkim-signature: |
v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1296757551; bh=iHfFeRdxYKuQ6yE0RYW6x0cHqap84dHP3SjcGJ+xQDc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=b8tVcAeKw7b/Eeg/WPVWCm7hc2GN4x627VqQ7Q 2Gr3F/Hi6dM0NdOgvxthwpJZM2QSMe4AGYiHS2xZUNNXdlFU5fV9iQ5ksmcXYPGnr93 Xl2iGtjHwCcFX1N8fg9qDtJ0rmpu1+sTCODd9b4bl6psL69gyqzzAdA9Y7w6xUvq1Y= |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4D49D0E6.30102@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> |
|
Mail-followup-to: |
Borislav Petkov <bp@xxxxxxxxx>, "H. Peter Anvin" <hpa@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> |
|
References: |
<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> <4D49D0E6.30102@xxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Wed, Feb 02, 2011 at 01:47:18PM -0800, H. Peter Anvin wrote:
> 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.
So, after staring at grub legacy sources a bit, we could load the
microcode image using the grub module's mechanism:
kernel /...
module /boot/microcode.gz type=SETUP_MICROCODE # this is looked at by
parse_setup_data()
and let grub write the pointer into setup_data passed through the kernel
header.
This would mean that we need to add support to a bunch of boot loaders
used currently, no? Or is there an even better way?
--
Regards/Gruss,
Boris.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home