Xen devel - Jun 2007 - 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 was wondering if there is some documentation on this or someone may be
able to help me out.
Thanks,
Girish


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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Girish V
> Sent: 24 June 2007 19:37
> To: xen-devel@lists.xensource.com
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Basically, "what Mats said" ;-)
> 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.
Also in the specific case of PV guests: paravirtualised guests can take system 
call software interupts directly without Xen having to get involved (although 
if privileged operations are required to implement the system call, Xen may 
need to get involved during the call handler).
> [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
Did something get missed off here?

Cheers,
Mark
> [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@lists.xensource.com
> http://lists.xensource.com/xen-devel


-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

> -----Original Message-----
> From: M.A. Williamson [mailto:maw48@hermes.cam.ac.uk] On 
> Behalf Of Mark Williamson
> Sent: 27 June 2007 01:35
> To: xen-devel@lists.xensource.com
> Cc: Petersson, Mats; Girish V
> Subject: Re: [Xen-devel] Anatomy of a trap
> 
> Basically, "what Mats said" ;-)
> 
> > 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.
> 
> Also in the specific case of PV guests: paravirtualised 
> guests can take system 
> call software interupts directly without Xen having to get 
> involved (although 
> if privileged operations are required to implement the system 
> call, Xen may 
> need to get involved during the call handler).
> 
> > [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
> 
> Did something get missed off here?
Yes, it''s meant to say "frontend/backend solution is the accepted
method
of doing this" - or something like that. 

Thanks for spotting it. 

--
Mats
> 
> Cheers,
> Mark
[snip]



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