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
