Re: [Xen-users] How to set up trivial shared-memory buffer between VMs (on ARM) ?

["Chris (Christopher) Brand" <chris.brand@xxxxxxxxxxxx>]

Thanks, Ian.

I've been going through the net front and back end drivers. These seem like a 
good model for what I'm trying to do.

What I don't understand is how the virtual device gets created. When the 
drivers get installed, they register with xenbus, and then all the actual 
communication setup happens in the respective probe functions, but what 
triggers the kernel to call those probe functions ? I guess in the blk/net case 
this ties in to the config file for the guest...?

Thanks,

Chris

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: Friday, 02 October, 2015 1:57 AM
> To: Chris (Christopher) Brand; xen-users@xxxxxxxxxxxxx
> Subject: Re: [Xen-users] How to set up trivial shared-memory buffer
> between VMs (on ARM) ?
> 
> On Thu, 2015-10-01 at 23:20 +0000, Chris (Christopher) Brand wrote:
> > Hi,
> >
> > I want to set up a simple shared-memory buffer between two VMs on my
> > ARM system.
> > I was looking at the passthrough stuff, hoping that that might work,
> > but it does seem tightly coupled to the use of an IOMMU, which my
> > system doesnât have. (
> > https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pd
> > f w as very helpful for exploring this path, BTW). Itâs fairly trivial
> > to move a block of RAM from the memory node to âdeviceâ node in the
> > devicetree for Xen, which makes it available to Dom0, but how can I
> > then share it with another VM ?
> 
> IOMMU's etc are certainly the wrong direction to be looking. The usual way
> to do this in a Xen system is for one end to allocate some memory and use
> the grant table to expose it to its peer, with the reference usually being
> communicated via xenstore.
> 
> libvchan is a userspace library which takes care of some of the grunt work on
> both client and server end, or alternatively there are some frameworks in
> the Linux kernel which can be used to help write drivers (checkout e.g.
> either the net or blk front and back for example, unfortunately the in -kernel
> ones tend to be for more complex cases).
> 
> > For context, I have an existing Linux kernel driver that I want to try
> > out under Xen. I suspect that the best way to do so is to migrate it
> > to use virtio, but for now I just need to get it running as quickly as
> > possible, so Iâd like to minimize the changes needed.
> 
> The existing driver should Just Work in dom0, so I suppose you are wanting
> to expose the device to a domU (which I suppose is why you were thinking
> of doing passthrough). In which case some sort of PV protocol to expose the
> functionality is the way to go.
> 
> Depending on the type of device you may find a higher level PV abstraction is
> better to work with than exposing something "device like".
> 
> >
> > Thanks,
> >
> > Chris
> > P.S. Please move the devel list if thatâs more appropriate
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users