Re: [Xen-devel] architecture for backend domains

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> o it seems from the docs that its possible to assign io privileges and
> administrative privileges to *any* domain (apart from dom0, which has
> these privileges built in IIRC). is this correct?

Yes, that's correct. I'm not sure how it's currently plumbed through
in the control tools, but Xen certainly supports this.

> o can there be multiple backend domains for a single physical device
> (like a network interface)? if so, then there is a scheduling involved
> at multiple levels -- first Xen will have to schedule backends across
> the physdev, and then each backend will have to schedule across the
> domains that use it as backend. Further, what mechanism does Xen use
> to determine which backend to direct pkts to and from the backend
> which client domain to forward them to?

There is a single backend domain and driver per physical device. This
single driver supports multiple backend interfaces (usually one per
frontend). The driver itself is then responsible for scheduling and
demux. 

> o if there is just one backend, how exactly does access to the devices
> take place? From the docs, I gather that each domain using the device
> has 2 rings -- one for sends and one for receivs (very generally
> speaking). Also, the docs say that the backend can directly map
> buffers of the virtual domains in Xen to enable DMA to them. But at
> other places in the docs, I got the impression that client domains
> (and not just backends) have these descriptor rings as well. So
> basically I'm asking if all communication happens through the backend,
> or do client domains talk directly to Xen.

Virtual domains do I/O via device channels that connect them to an
appropriate backend driver. A channel connects a frontend interface to
a backend interface. The channel comprises an event channel for
notifications plus a shared-memory region that contains asynchronous
messaging rings. 

Xen knows nothing about particular I/O devices (it contains only a
serial-line driver, for debugging). Clients do not talk to Xen to get
their I/O work done --- it is *all* done via inter-domain comms.

 -- Keir


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel