WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Shared memory and event channel

To: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] Shared memory and event channel
From: Ritu kaur <ritu.kaur.us@xxxxxxxxx>
Date: Sun, 21 Feb 2010 15:33:30 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 21 Feb 2010 15:34:16 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rSx+WWmWvMtAidAj/8vKwHRAIHuYiWol+Q2YHTy1nW8=; b=QDRRu+LQkWquZUmhqGwMcZ6Zs+zbmQwFfrHTBKc4+kU4yL2rYiPFKcf42sOsXtEFdI QcxqZuf3M7WVZK/87IC6E0y4xZLq2+4U9XkggqmpNkdEnD3IGmFHosXd2LiccjBpbMk4 AAF2rgKpNuuuZu7hv4M0Vuqm4arSQleuLCVyk=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CSq0bbE4xhUIHB00SVwfQYQq+nEnnMr4QFweVAbecZ3OGznqho0cdAGGK5pT9x/TB1 eK3S/enP9eShoTx6MaBzpFuRyTF3leYCBAWXC8hrg856O9T89Um57ZkiKGkK8f6LoeKd pv/+3EJgrkMyEZd36Gp1F/GVwAEbJWinZAQ8Y=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1266787199.24577.18.camel@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <29b32d341002211058l7e283336pa4fdfd0dc0b7124b@xxxxxxxxxxxxxx> <1266787199.24577.18.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxx> 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


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