Re: Shared memory and event channel

[Ritu kaur <ritu.kaur.us@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3833 bytes --]

Hi Daniel,

Thanks for the explanation, however, my main question is still unanswered

"My understanding is one has to use xenbus(registering and monitoring for
device creation) mechanism to setup shared mem rings and event channel
between dom's and there is no other way to do it."

All I need is to setup NIC register reads and writes from domUs(ioctl is one
such application which I have been discussing in another thread) and to
implement this I considered an option of using shared memory rings. If
answer to the above question is "Yes" then probably I will not take that
route.

It will be really helpful if you can elaborate on "why not just write an
auxiliary driver adding only added functionality but remaining separate from
the base networking stack"

Thanks


On Sun, Feb 21, 2010 at 1:19 PM, Daniel Stodden
<daniel.stodden@citrix.com>wrote:

> On Sun, 2010-02-21 at 13:58 -0500, Ritu kaur wrote:
> > Hi,
> >
> > This is related to my other thread(ioctls) but thought this subject
> > mandates a seperate thread by itself. Below is what my understanding,
> > inputs and correction will be very helpful
> >
> > 1. in order to setup shared memory rings and event channels a
> > frontend(running in domU) and backend(running in dom0) drivers are
> > required.
>
> Yes, and device instances come in pairs.
>
> > 2. these drivers registers with xenbus, monitor for a device creation
> > in xenstored.
>
> Yes. The backend device is created as soon as node <domid>/<devid> in
> backend/<type> is created. Resulting in a .probe event on the respective
> driver. Frontend device creation work equivalently.
>
> > 3. when devices are created, xenbus invokes backend/frontend probe
> > functions which then triggers xenbus state machine.
>
> Yes. The "state" field on either end drives frontend/backend connection
> setup and teardown. These are the "otherend_changed" callbacks in the
> xenbus drivers.
>
> > 4. before xenbus state machine gets into connected state, shared
> > memory and event channels are setup and using hypervisor calls can be
> > accessed.
>
> Right. You will find two grant references for the I/O rings. One ring
> for RX and TX, respectively. This memory is allocated by domU and
> granted to the 'otherend' (=backend) domain. The grant reference is an
> index into a table maintained by domU, which contains the sharing
> permissions.
>
> The other important key is the descriptor for a bidirectional
> ('interdomain') event channel. This is basically the interrupt line used
> to notify the remote end when messages are produced on either ring.
>
> > My understanding is one has to use xenbus(registering and monitoring
> > for device creation) mechanism to setup shared mem rings and event
> > channel between dom's and there is no other way to do it.
> >
> > If I had to write a new driver I should have a new device name and my
> > driver will monitor this device via xenbus. In order to have new
> > device supported, I have to modify xapi toolstack, so it looks like
> > lot of changes has to be done to support this. I wish to be wrong
> > here. If there is an alternate mechanism to do it I would like to
> > know. Inputs much appreciated.
>
> Why do you need a different driver? Essentially: Why aren't your network
> frontends happy with the existing abstractions? What exactly is the
> functionality you want to add?
>
> Collecting statistics or low level DMA setup, as you mentioned, sounds a
> lot like details better kept in dom0. Why would domU have to bother, it
> should even be allowed to to anything about it.
>
> Even assuming it's a good idea to add these calls:
>
> Why would you need to reinvent the entire networking wheel? Why  not
> just write an auxiliary driver adding only added functionality, but
> remaining separate from the base networking stack?
>
> Cheers,
> Daniel
>
>

[-- Attachment #1.2: Type: text/html, Size: 4675 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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