Xen devel - May 2007 - DomU-Dom0 communication question

Hi all,

I need to create a custom communication channel between DomU and Dom0 in order
to send arbitrary messages/buffers between applications in Dom0 and DomU.

Basically, I am thinking about making a char control driver on both sides that
would transport those messages to subscribers on either end using defined IOCL
calls.

I am looking at backend/frontend drivers and I don''t think it would
work for what I want to do as fron/back ends don''t have any devices
associated with it.

Would it be better to utilize event channel directly or write frontend/backend
drivers and control drivers on both ends? Or maybe there is another mechanism
that already exists in xen environment and I am just trying to do things the
hard way? Any advise is greatly appreciated.

Thanks.

Max

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

On 5/2/07, mk.xen-devel@simplecheck.net <mk.xen-devel@simplecheck.net>
wrote:
>
> Hi all,
>
> I need to create a custom communication channel between DomU and Dom0 in
> order to send arbitrary messages/buffers between applications in Dom0 and
> DomU.

That sounds strangely familiar to what I had to do last month.  Basically
building a mechanism to transport arbitrary strings out of the guest and
into Dom0.

Basically, I am thinking about making a char control driver on both
sides
> that would transport those messages to subscribers on either end using
> defined IOCL calls.

Seems very doable.

I am looking at backend/frontend drivers and I don''t think it would
work for
> what I want to do as fron/back ends don''t have any devices
associated with
> it.
>
Hmm, it sounds like you may be a bit confused regarding how the split
drivers work.  For any useful frontend/backend device each side ends up
being two drivers in one.  One is the frontend/backend driver, the other is
the device that the OS sees.  For example, the networking frontend has all
of the code the being a Xen frontend driver (event channels, probe handling,
etc) and is also a network device that the guest interacts with.  In a sense
it registers itself as two drivers.

You could definitely write a split driver that has character devices on both
ends that share data.  My backend driver for the project I mentioned above
is exactly that.  (Frontend kernel puts data onto a ring buffer, backend
kernel reads it off and makes it available as a character device.)

Would it be better to utilize event channel directly or
write
> frontend/backend drivers and control drivers on both ends? Or maybe there
is
> another mechanism that already exists in xen environment and I am just
> trying to do things the hard way? Any advise is greatly appreciated.

This probably sounds bad, but if you can get away with it I would do
everything is user space and send your arbitrary data/buffers over the
network link.  Trust me when I say that you''ll lose less hair that way.

If you decide to go the split driver route, I can supply you with my code.
It isn''t pretty, but it may help you out.  Let me know if
you''re interested.

Thanks
Ryan


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

On 5/2/07, Ryan Riley <rileyrd@gmail.com> wrote:
> > I am looking at backend/frontend drivers and I don''t think it
would work
> for what I want to do as fron/back ends don''t have any devices
associated
> with it.
> > 
> 
> Hmm, it sounds like you may be a bit confused regarding how the split
> drivers work.  
Yes, I am :-)
> For any useful frontend/backend device each side ends up
> being two drivers in one.  One is the frontend/backend driver, the other is
> the device that the OS sees.  For example, the networking frontend has all
> of the code the being a Xen frontend driver (event channels, probe
handling,
> etc) and is also a network device that the guest interacts with.  In a
sense
> it registers itself as two drivers. 
That is the driver I was going through to get an idea how it works. I see the
network adapter registration part, but since I am not familiar with network
drivers APIs I got confused what exactly is going on.
> You could definitely write a split driver that has character devices on
both
> ends that share data.  My backend driver for the project I mentioned above
> is exactly that.  (Frontend kernel puts data onto a ring buffer, backend
> kernel reads it off and makes it available as a character device.) 
Sounds exactly what I need, except I was thinking to have messages in both
directions.
> This probably sounds bad, but if you can get away with it I would do
> everything is user space and send your arbitrary data/buffers over the
> network link.  Trust me when I say that you''ll lose less hair that
way.
I think, the split drivers give me a better control for the task I am doing. I
do not want to rely on network being setup correctly.
> If you decide to go the split driver route, I can supply you with my code. 
> It isn''t pretty, but it may help you out.  Let me know if
you''re interested.
I am definitely  interested! I was out of writing Linux drivers for quite some
time and I appreciate any help I can get.

Thanks.

Max

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