Re: [Xen-users] Why the unmodified guest os can run on xen while hardware supports VT?

[Javier Guerra <javier@xxxxxxxxxxx>]

On Sunday 26 November 2006 8:49 pm, Eric Zhang wrote:
>     I know that xen will run in "ring 0" in x86's protection mode and
> xen will run the guest OS in "ring 1", this is done by modifying the
> guest OS's kernel codes. My question is why we shouldn't modify the
> guest os's kernel while the hardware supports VT technology -- such as a
> Intel's CPU which supports VT.

forgive me if i think your question doesn't make much sense if read textually.  
i guess it's just a language limitation, this is what i believe you wanted to 
ask:

"I know that Xen itself (the hypervisor) runs in ring 0 and the guest OS's 
kernel in ring 1, to do this, it's needed to modify the guest OS's kernel 
(paravirtualization).  My question is how we can run an unmodified guest OS's 
kernel when the hardware supports VT technology"

If this is what you want to know, let me try to explain a little:

The rings mechanism implemented by Intel processors since the 80386 (now 
called IA32 or simply x86) lets a piece of code 'manage' what a different 
code can do, simply by running the managed code in a higher ring than the 
manager.   the manager sets exception handlers that are called each time 
something special happens on the managed code, like memory page faults, 
instruction exceptions, etc.

unfortunately, x86 provides a limited set of rings (0 is the most privileged, 
3 is the least); and there are some things that can only be done on ring 0. 
(mostrly very low level hardware accesses).  therefore, usual unmodified 
kernels are run only at ring 0.

other processors (i.e. almost anyone from IBM) provide full virtualization 
facilities: an hypervisor can setup an environment basically identical to the 
bare processor (that's what MoL (mac on linux) does to run MacOS on top of 
PPC linux)

existing virtualization software, like VMWare, virtualPC, and Qemu (with 
kqemu) manage to work by doing a very complex set of tricks: set several 
exception handlers to cover most of anything that the guest kernel might do, 
and scanning each piece of guest code before running it, replacing any 
instruction that would have a non-desired effect with a call to an emulator 
that does what _should_ happen.

of course, there's some performance penalty, and very complex code. the fact 
that all these emulator/virtualization hybrids actually work (and very well) 
is very amazing to me.

the new HVM extensions to the x86 IA lets the hypervisor to setup new handlers 
for all the missing privileged instructions, effectively making it possible 
to run managed code in ring 0.  i think you could think of it like creating a 
new ring0.5 for the guest OS's kernel, it can do anything ring 0 does, but 
managed by a "real ring 0" where the hypervisor resides.

the rest of the problem is the emulation of the rest of the hardware: the 
chipset, PCI controller, network, hard disk, cdrom, graphics card, etc.  for 
this, the Xen hypervisor forward any hardware access to a slightly modified 
qemu process running in domain 0.

i hope this makes it all a bit clearer, and that i'm not too wrong on some 
points.

-- 
Javier

Attachment: pgp0UV3MS6fqo.pgp
Description: PGP signature

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users