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

Re: [Xen-devel] Porting of Guest OS

To: "Ronald G. Minnich" <rminnich@xxxxxxxx>
Subject: Re: [Xen-devel] Porting of Guest OS
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 31 Dec 2004 09:53:52 +0000
Cc: Amitabh Tamhane <amitabh_2k@xxxxxxxxxxx>, maw48@xxxxxxxxxx, fajar@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 31 Dec 2004 09:55:27 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 30 Dec 2004 18:58:04 MST." <Pine.LNX.4.58.0412301857040.14925@xxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> 
> 
> On Thu, 30 Dec 2004, Amitabh Tamhane wrote:
> 
> > During boot-up:
> > 1) Applying Intel IA32 Microcode update: insmod:
> > /lib/modules/2.6.5-7.97-smp/kernel/arch/i386/kernel/microcode.o: insmod
> > char-major-10-184 failed

That's the wrong module anyway -- it's from a native kernel not a
Xen-ported kernel.

> is it safe to assume that code in Ring 1 can't upgrade microcode :-)?
> I'd say that the microcode module would surprise me if it worked. 
> 
> ron

A privileged domain can use the RDMSR/WRMSR Xen functions. In the
unstable tree it can even execute RDMSR/WRMSR directly and Xen will
emulate them.

The main difficulty is that currently we only execute the MSR accesses
on the CPU on which the domain is running. We could easily change the
default to be to write to all CPUs -- that would make more sense for
microcode updates, but I'm not sure if it would be silly for other
things. 

The other difficulty is that a microcode update needs several MSR
updates per CPU that need to happen with no other overlapping
updates.

The microcode driver is pretty small, so we may end up putting it in
Xen, as we did with the MTRR code. 

 -- Keir


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

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