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
