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
pgp0LBalKd47s.pgp
Description: PGP signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home