| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Anatomy of a trap
> -----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
|
|
|
| |
|
Home