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

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

[Stefano Stabellini]

From: Stefano Stabellini <stefanos@xilinx.com>

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@xilinx.com>
Cc: julien.grall@arm.com
---
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.
+
+For each of these pre-shared memory regions, a range is exposed under
+the /reserved-memory node as a child node. Each range sub-node is named
+xen-shmem@<address> and has the following properties:
+
+- compatible:
+	compatible = "xen,shared-memory-v1"
+
+- reg:
+	the base guest physical address and size of the shared memory region
+
+- xen,id:
+	a string that identifies the shared memory region as specified in
+	the VM config file
-- 
1.9.1


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

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

[Julien Grall]

Hi,

On 10/24/18 2:18 AM, Stefano Stabellini wrote:
> From: Stefano Stabellini <stefanos@xilinx.com>
> 
> 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@xilinx.com>
> Cc: julien.grall@arm.com
> ---
> 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?

> +
> +For each of these pre-shared memory regions, a range is exposed under
> +the /reserved-memory node as a child node. Each range sub-node is named
> +xen-shmem@<address> and has the following properties:
> +
> +- compatible:
> +	compatible = "xen,shared-memory-v1"
> +
> +- reg:
> +	the base guest physical address and size of the shared memory region
> +
> +- xen,id:
> +	a string that identifies the shared memory region as specified in
> +	the VM config file
> 

Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2018-10/msg00730.html

-- 
Julien Grall

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

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

[Stefano Stabellini]

On Wed, 31 Oct 2018, Julien Grall wrote:
> Hi,
> 
> On 10/24/18 2:18 AM, Stefano Stabellini wrote:
> > From: Stefano Stabellini <stefanos@xilinx.com>
> > 
> > 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@xilinx.com>
> > Cc: julien.grall@arm.com
> > ---
> > 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.

I'll send an update to this proposal adding the offset.

> > +
> > +For each of these pre-shared memory regions, a range is exposed under
> > +the /reserved-memory node as a child node. Each range sub-node is named
> > +xen-shmem@<address> and has the following properties:
> > +
> > +- compatible:
> > +	compatible = "xen,shared-memory-v1"
> > +
> > +- reg:
> > +	the base guest physical address and size of the shared memory region
> > +
> > +- xen,id:
> > +	a string that identifies the shared memory region as specified in
> > +	the VM config file
> > 
> 
> Cheers,
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2018-10/msg00730.html


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

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

[Julien Grall]

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@xilinx.com>
>>>
>>> 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@xilinx.com>
>>> Cc: julien.grall@arm.com
>>> ---
>>> 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?

Cheers,

-- 
Julien Grall

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

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

[Stefano Stabellini]

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@xilinx.com>
> > > > 
> > > > 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@xilinx.com>
> > > > Cc: julien.grall@arm.com
> > > > ---
> > > > 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Julien Grall]

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@xilinx.com>
>>>>>
>>>>> 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@xilinx.com>
>>>>> Cc: julien.grall@arm.com
>>>>> ---
>>>>> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Ian Jackson]

Julien Grall writes ("Re: [PATCH v3] devicetree,xen: add xen,shared-memory binding"):
> On 11/1/18 8:40 PM, Stefano Stabellini wrote:
> >  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.

libxl doesn't see the actual mappings, does it ?  It just puts things
into the p2m.

Ian.

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

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

[Julien Grall]

Hi Ian,

On 02/11/2018 15:30, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH v3] devicetree,xen: add xen,shared-memory binding"):
>> On 11/1/18 8:40 PM, Stefano Stabellini wrote:
>>>   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.
> 
> libxl doesn't see the actual mappings, does it ?  It just puts things
> into the p2m.

Yes. That's why I think multiple mappings is actually possible.

Cheers,

-- 
Julien Grall

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