Re: [Xen-devel] [PATCH v3] devicetree, xen: add xen, shared-memory binding

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 11/1/18 8:40 PM, Stefano Stabellini wrote:
> On Thu, 1 Nov 2018, Julien Grall wrote:
> > Hi,
> >
> > On 11/1/18 8:31 PM, Stefano Stabellini wrote:
> > > On Wed, 31 Oct 2018, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 10/24/18 2:18 AM, Stefano Stabellini wrote:
> > > > > From: Stefano Stabellini <stefanos@xxxxxxxxxx>
> > > > >
> > > > > Introduce a device tree binding for Xen reserved-memory regions. They
> > > > > are used to share memory across VMs from the VM config files. (See
> > > > > static_shm config option.)
> > > > >
> > > > > Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
> > > > > Cc: julien.grall@xxxxxxx
> > > > > ---
> > > > > Changes in v3:
> > > > > - remove fallback version
> > > > >
> > > > > Changes in v2:
> > > > > - fix Author line
> > > > > - add versioning
> > > > > - xen,id instead of id
> > > > > ---
> > > > >     .../bindings/reserved-memory/xen,shared-memory.txt   | 20
> > > > > ++++++++++++++++++++
> > > > >     1 file changed, 20 insertions(+)
> > > > >     create mode 100644
> > > > > Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > > > > b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > > > > new file mode 100644
> > > > > index 0000000..7c81683
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > > > > @@ -0,0 +1,20 @@
> > > > > +* Xen hypervisor reserved-memory binding
> > > > > +
> > > > > +Expose one or more memory regions as reserved-memory to the guest
> > > > > +virtual machine. Typically, a region is configured at VM creation time
> > > > > +to be a shared memory area across multiple virtual machines for
> > > > > +communication among them.
> > > > I may have notice some issue with this binding. Looking at the design
> > > > document
> > > > [1], the "master" domain may provide a big backing region that would be
> > > > split
> > > > and share with multiple "slave".
> > > >
> > > > For the "master" domain, this binding would specify the full backing
> > > > region.
> > > > The "master" OS would not be able to know how the region would be used
> > > > here.
> > > >
> > > > For the "slave" domain, it looks like it might be possible to map the same
> > > > region (so same ID) twice. So we would end up to create the same bindings
> > > > twice.
> > > >
> > > > Any opionion on how we should proceed with these two use cases?
> > > Julien and I discussed this morning to clarify that regions shouldn't be
> > > mapped twice in the Xen docs, and adding an "offset" property to this
> > > binding.
> > Well, why would you forbid the mappings twice if the offset is present?
>  From the DT binding point of view, it would be fine. Conceptually it
> would also be fine. However, I doubt that the current libxl
> implementation would work with multiple mappings.
I can't see why it would not work. I think we designed the refcount for 
this purpose.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel