> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Girish V
> Sent: 24 June 2007 19:37
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Anatomy of a trap
>
> Hello,
> I am a newbie at xen - I am trying to trace the complete
> execution of a trap.
>
> Specifically, I am trying to find out where the control
> transfer happens between a domU to dom0 when a trap occurs,
> and where the control switches back to domU after the trap is
> handled.
I think you've misunderstood something. Dom0 doesn't get involved with
DomU traps [at least not directly, see below].
The hypervisor always takes all traps. In some cases, the guests fault
isn't forwarded to the guest, because the reason for the trap is that
the hypervisor needs to know what's going on and emulate the operation
(e.g. a write to CR3), so we just emulate the instruction in whatever
way necessary. This also applies to certain page-faults that are to do
with writing the page-table, for example.
In the case where the guest is actually "causing the trap itself", then
the hypervisor keeps a list of handlers for the respective guest, and it
just calls that handler (do_guest_trap). This is set by the
"do_set_trap_table", which is a hypercall function from the guest.
There are of course cases where Dom0 does get involved, but that's as a
side-effect of a trap, rather than directly because of the trap. For
example, if we have a DomU that has swap-space in an image-file [1], a
page-fault that causes a read or write to the swap file, the
block-device driver in the DomU (frontend) will cause the Dom0 backend
[2] to wake up and perform the relevant read or write to the actual
swap-space file. So whilst the source of the read/write operation to the
image was a trap, the transaction with Dom0 a direct consequence of the
trap.
[1] Or a disk that isn't OWNED by DomU itself. DomU can only own entire
PCI devices, such as disk controllers (e.g. a SCSI, SATA or IDE
controller). It must own the WHOLE controller, as individual disks
aren't separated well enough within the disk controller, and the context
within the controller can only be consistant under one owner domain -
unless we add an interface to the entire system to support multiple
domain-locking from one device, and that wouldn't exactly be easy -
every device driver in the entire Linux source code would have to be
touched in MANY places. Since that's not likely to be feasible, the
frontend/backend
[2] The backend doesn't have to be in Dom0 - any domain can be made into
a driver-domain. It is NORMALLY Dom0, but doesn't have to be. It'll be
the driver domain that is being woken up - so if it's not Dom0, then
Dom0 will have nothing at all to do with the trap.
>
> I was wondering if there is some documentation on this or
> someone may be able to help me out.
> Thanks,
> Girish
Sorry, but I don't know of any direct documentation. You may want to
look at .../xen/arch/x86/traps.c
Particularly the functions:
do_set_trap_table()
do_guest_trap()
.../linux*/arch/x86_64/kernel/traps-xen.c
Particularly:
trap_init()
--
Mats
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home