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

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



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.

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

 


Rackspace

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