XenStore as a data transfer path?

XenStore as a data transfer path?

[Larry White]

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

Can the XenStore database be accessed by domU's?  

 

If so, could it be used to pass small amounts of data back and forth between
dom0 and domU's using XenStore key entries?  If this is possible, it would
seem that this could eliminate the need to create a "device" driver for a
simple communication path.

 

Also, what type of Guest Fedora Kernel would be needed to perform this type
of Xen functionality in a HVM domU guest configuration?  I assume that a
normal Fedora kernel would not work.  However, I have read the Fedora 14 and
later has some type of Xen support out of the box.  Not sure what type of
support.

 

Thanks,

Larry

 


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

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

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

Re: XenStore as a data transfer path?

[James Harper]

> 
> Can the XenStore database be accessed by domU's?
> 

Yes. That is how the frontend/backend devices set up their communication channels.

> 
> If so, could it be used to pass small amounts of data back and forth between
> dom0 and domU's using XenStore key entries?  If this is possible, it would
> seem that this could eliminate the need to create a "device" driver for a
> simple communication path.
> 

Yes, for certain values of "small". Can you say more about the sort of data you would be passing? In particular the throughput and latency requirements?

James

Re: XenStore as a data transfer path?

[Larry White]

-----Original Message-----
From: James Harper [mailto:james.harper@bendigoit.com.au] 
Sent: Friday, July 20, 2012 8:44 PM
To: Larry White; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] XenStore as a data transfer path?

> 
> Can the XenStore database be accessed by domU's?
> 

>>Yes. That is how the frontend/backend devices set up their communication
>>channels.

Are you saying that the actual data going back and forth gets put into the
XenStore?  I thought that the XenStore was mostly used for configuration
keyword values and such that the underlying drivers needed.

> 
> If so, could it be used to pass small amounts of data back and forth
between
> dom0 and domU's using XenStore key entries?  If this is possible, it would
> seem that this could eliminate the need to create a "device" driver for a
> simple communication path.
> 

>>Yes, for certain values of "small". Can you say more about the sort of
>>data you would be passing? In particular the throughput and latency
>>requirements?

I would say that the small amount of data here per transfer would be around
32 bytes in length with a latency of around 500ms or so.

Larry

Re: XenStore as a data transfer path?

[James Harper]

> >
> > Can the XenStore database be accessed by domU's?
> >
> 
> >>Yes. That is how the frontend/backend devices set up their
> >>communication channels.
> 
> Are you saying that the actual data going back and forth gets put into the
> XenStore?  I thought that the XenStore was mostly used for configuration
> keyword values and such that the underlying drivers needed.
> 

Yes. It's how they set up their communication channels. The communication channels are shared pages of memory and event channels, but they use xenstore to set it up (eg so the backend can find the address of the frontend ring.

> >
> > If so, could it be used to pass small amounts of data back and forth
> between
> > dom0 and domU's using XenStore key entries?  If this is possible, it
> > would seem that this could eliminate the need to create a "device"
> > driver for a simple communication path.
> >
> 
> >>Yes, for certain values of "small". Can you say more about the sort of
> >>data you would be passing? In particular the throughput and latency
> >>requirements?
> 
> I would say that the small amount of data here per transfer would be around
> 32 bytes in length with a latency of around 500ms or so.
> 

How fast though? Is it 32 bytes every 1ms, or 32 bytes every 20 seconds?

James

Re: XenStore as a data transfer path?

[Larry White]

Hi James,
Thanks for your help with this.  I am brand new to Xen, so I appreciate the
information so I can get started on the correct path.


-----Original Message-----
From: James Harper [mailto:james.harper@bendigoit.com.au] 
Sent: Saturday, July 21, 2012 7:01 AM
To: Larry White; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] XenStore as a data transfer path?

> >
> > Can the XenStore database be accessed by domU's?
> >
> 
> >>Yes. That is how the frontend/backend devices set up their
> >>communication channels.
> 
> Are you saying that the actual data going back and forth gets put into the
> XenStore?  I thought that the XenStore was mostly used for configuration
> keyword values and such that the underlying drivers needed.
> 

>>Yes. It's how they set up their communication channels. The communication
>>channels are shared pages of memory and event channels, but they use
>>xenstore to set it up (eg so the backend can find the address of the
>>frontend ring.

I realize XenStore is used to help setup these channels.  However, for some
reason, I was thinking if this information is visible between both dom0 and
domU, I could use it to pass my data back and forth through.  Currently, my
domU Fedora Kernel is a plain vanilla version configured as a HVM which may
not be able to access the XenStore (not sure about this).  Do I need a
special guest kernel to perform Xen communication with dom0?  If so, what
about Windows?  Is there a special Guest Xen windows binary also for it?

I guess I was thinking that a simple XenStore only approach would eliminate
having to setup a split-driver model that utilized ring-buffers and such.
Of course, I can certainly do this if this is the correct thing to do.  I
just didn't think it had to be too complicated for such a small amount of
data that needs to be transferred.

> >
> > If so, could it be used to pass small amounts of data back and forth
> between
> > dom0 and domU's using XenStore key entries?  If this is possible, it
> > would seem that this could eliminate the need to create a "device"
> > driver for a simple communication path.
> >
> 
> >>Yes, for certain values of "small". Can you say more about the sort of
> >>data you would be passing? In particular the throughput and latency
> >>requirements?
> 
> I would say that the small amount of data here per transfer would be
around
> 32 bytes in length with a latency of around 500ms or so.
> 

>>How fast though? Is it 32 bytes every 1ms, or 32 bytes every 20 seconds?

32 bytes every 500ms (1/2 second).

Larry

Re: XenStore as a data transfer path?

[Larry White]

Hi Konrad,

>On Tue, Jul 17, 2012 at 11:22:28PM -0500, LarryWhite wrote:
>I am new to Xen and want to provide simple communication between my DomU
>and
>Dom0 environments.  I just need to be able to pass a few bytes of
>information back and forth between DomU and Dom0 while using some form of
>event management to know when an update occurs so I can act on it.  At
>first, it appeared that using XenBus and XenStore might be the right
>solution for this.  However, after looking over the documentation, it seems
>that XenBus and XenStore should only be used in a PVM Xen configuration,
>not
>a HVM model like mine.  Is this true?  

>>It can be done in HVM.

>What would be the best way to accomplish this?  Is there any sample code
>which demonstrates this for a HVM Xen environment?

>>libvchan is your best bet.

Have been looking at libvchan as you suggested.  An additional bit of
information that I left out on my original post was that I would like to do
this in a "one to many" environment.  In other words, I want to support data
transfer from dom0 to a number of different domU's.  Would an approach such
as libvchan allow for this or would I need a separate process in dom0 for
each of the different domU channels?  I was really hoping to have a single
process running in dom0 to manage this. 

Thanks,
Larry

Re: DomU to Dom0 Communication in Xen HVM?

[Larry White]

Hi Konrad,

>On Tue, Jul 17, 2012 at 11:22:28PM -0500, LarryWhite wrote:
>I am new to Xen and want to provide simple communication between my DomU
>and
>Dom0 environments.  I just need to be able to pass a few bytes of
>information back and forth between DomU and Dom0 while using some form of
>event management to know when an update occurs so I can act on it.  At
>first, it appeared that using XenBus and XenStore might be the right
>solution for this.  However, after looking over the documentation, it seems
>that XenBus and XenStore should only be used in a PVM Xen configuration,
>not
>a HVM model like mine.  Is this true?  

>>It can be done in HVM.

>What would be the best way to accomplish this?  Is there any sample code
>which demonstrates this for a HVM Xen environment?

>>libvchan is your best bet.

Have been looking at libvchan as you suggested.  An additional bit of
information that I left out on my original post was that I would like to do
this in a "one to many" environment.  In other words, I want to support data
transfer from dom0 to a number of different domU's.  Would an approach such
as libvchan allow for this or would I need a separate process in dom0 for
each of the different domU channels?  I was really hoping to have a single
process running in dom0 to manage this. 

Thanks,
Larry

Re: XenStore as a data transfer path?

[George Dunlap]

On Sat, Jul 21, 2012 at 6:59 PM, Larry White <lmw@satx.rr.com> wrote:
>>>libvchan is your best bet.
>
> Have been looking at libvchan as you suggested.  An additional bit of
> information that I left out on my original post was that I would like to do
> this in a "one to many" environment.  In other words, I want to support data
> transfer from dom0 to a number of different domU's.  Would an approach such
> as libvchan allow for this or would I need a separate process in dom0 for
> each of the different domU channels?  I was really hoping to have a single
> process running in dom0 to manage this.

Depending on how "bleeding edge" you want to be, you may want to look
at the v4v patchset as well (currently under discussion).  I believe
one of the features of v4v was the ability to do one-to-many.

Regarding using XenStore for data transfer: it is, of course,
technically possible; but I think we want to discourage people from
doing that, as xenstore wasn't really designed for that purpose. I
don't think it should be relied on for latency, and using it as a
communication channel may have unfortunate side-effects on other users
of xenstore.

 -George

Re: XenStore as a data transfer path?

[Konrad Rzeszutek Wilk]

On Sat, Jul 21, 2012 at 12:59:31PM -0500, Larry White wrote:
> Hi Konrad,
> 
> >On Tue, Jul 17, 2012 at 11:22:28PM -0500, LarryWhite wrote:
> >I am new to Xen and want to provide simple communication between my DomU
> >and
> >Dom0 environments.  I just need to be able to pass a few bytes of
> >information back and forth between DomU and Dom0 while using some form of
> >event management to know when an update occurs so I can act on it.  At
> >first, it appeared that using XenBus and XenStore might be the right
> >solution for this.  However, after looking over the documentation, it seems
> >that XenBus and XenStore should only be used in a PVM Xen configuration,
> >not
> >a HVM model like mine.  Is this true?  
> 
> >>It can be done in HVM.
> 
> >What would be the best way to accomplish this?  Is there any sample code
> >which demonstrates this for a HVM Xen environment?
> 
> >>libvchan is your best bet.
> 
> Have been looking at libvchan as you suggested.  An additional bit of
> information that I left out on my original post was that I would like to do
> this in a "one to many" environment.  In other words, I want to support data
> transfer from dom0 to a number of different domU's.  Would an approach such
> as libvchan allow for this or would I need a separate process in dom0 for
> each of the different domU channels?  I was really hoping to have a single
> process running in dom0 to manage this. 

You would need seperate rings for each domU. Whether you want to implement this
in a single process or multi-thread the process - or just use one process and
block on the event (signal) to receive an interrupt when data appears - that is up
to you.

> 
> Thanks,
> Larry
> 
>