On Sun, 2008-03-09 at 10:27 +0800, 房海峰 wrote:
> hello, my friend:
>
> According to my research with source code of xen, i think the process
> is that:
>
> first, when Guest OS is created by Xen/Domian0, it install it's IDT
> through "set_trap_table" hypercall.
> second, during Xen/GuestOS running, all interrupt/trap will result a
> trap into Ring0, that is the layer of Xen.
> for some trap, such as system-call, they will be dealt with directly
> through interrupt hardware.
> For the most of other traps, they will be dealt by xen, and then
> dispatched to corresponding Guest OS.
>
> in addition, there are other details to study in-depth.
Generally, the IDT entry may either point to xen or directly to the
trap handler installed by the guest.
For system calls, it presently depends on the architecture: x86_32 has
separate trap instructions for hypercalls and system calls, which can be
forwarded directly. But is not the case for 64-bit systems.
In fault handling, it depends on the type of fault. It may be either due
to the virtualization layer, then transparently fixed by Xen (e.g.
instruction emulation). Or the guest may be responsible (e.g. a process
page fault). In that case the fault will be forwarded.
Some faults (e.g. division by zero) are indeed never Xen's business.
Still, you'll find the idt entry to point to xen, instead of directly to
the ring1 kernel. See the use of DO_ERROR_*() in x86/traps.c. The
reason is simply that bugs in Xen (of course, that's impossible :), but
you never know) would not be caught otherwise.
So, the bottom line is that all goes through Xen, except for 32-on-32
bit system calls.
hth,
daniel
--
Daniel Stodden
LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München D-85748 Garching
http://www.lrr.in.tum.de/~stodden mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|