[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Ian Campbell <ian.campbell@xxxxxxxxxx>, "xen-users@xxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxx>
  • From: "Chris (Christopher) Brand" <chris.brand@xxxxxxxxxxxx>
  • Date: Wed, 7 Oct 2015 20:19:08 +0000
  • Accept-language: en-US
  • Delivery-date: Wed, 07 Oct 2015 20:20:22 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>
  • Thread-index: AdD8nrxuplKaif/dTs+urlPl/Irz/QAjEcwAAM45KrAABL+B8AAo7/sAAAh5D5A=
  • Thread-topic: [Xen-users] How to set up trivial shared-memory buffer between VMs (on ARM) ?

Thanks, Ian! That was a great help. I've added my findings below for the

> > So libxl writes to xenstore as part of the creation of the new guest,
> > and that is triggered by the entries in the config file for the new
> > guest. So how can I do this for my device ? I tried running
> > xenstore-write (on
> > Dom0) to create an appropriate node, but that didn't seem to have any
> > effect (or maybe I'm doing something wrong...) I tried both before and
> > after running xl create.
> It should be possible to do with xenstore-write, you might find it easier to
> create the guest paused (-p), create the front _and_ backend nodes and
> then unpause the guest, but with hotplug the pause ought really to make no
> difference.

Indeed I found that it wasn't necessary to create the guest paused (it might
actually make things harder, because the frontend has to change state first,
but I didn't pursue this very far).

> Do you have a frontend driver and backend driver? Are you configuring both.
> In general f/e's require a backend node in xs pointing to their peer, but I'm
> not sure if this is implemented on a driver by driver basis or if the core is
> involved. I'm also not sure offhand which set of keys the core would require
> to exist before it did anything.

Yes, I have both a frontend and backend driver.

> http://wiki.xenproject.org/wiki/Introduction_to_Xen_3.x, which looks
> rather out of date so don't trust it too much, suggests:
> xenstore-write /local/domain/X/device/mydevice/0/state 1 xenstore-write
> /local/domain/0/backend/mydevice/X/0/frontend-id X xenstore-write
> /local/domain/0/backend/mydevice/X/0/frontend
> /local/domain/X/device/mydevice/0 xenstore-write
> /local/domain/0/backend/mydevice/X/0/state 1

There's a more complete script at the bottom of that wiki page that does seem
to do the trick. 6 writes and a chmod in total.

> as a minimal set. Personally I'd do it all with one:
>     xenstore-write KEY1 VALUE1 KEY2 VALUE2 KEY3 VALUE3 so it all gets done
> in a single transaction.

That doesn't seem to be necessary. The frontend probe is triggered by the write
of frontend state. It then finds the backend and sits waiting for it to come 
up. Then
the backend probe is triggered by the write of backend state (which has to be 
last). Now I just have to debug the actual driver probe itself :-)


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.