RE: [Xen-devel] Anatomy of a trap

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: M.A. Williamson [mailto:maw48@xxxxxxxxxxxxxxxx] On 
> Behalf Of Mark Williamson
> Sent: 27 June 2007 01:35
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel