On 10/27/2022 12:55 PM, Krzysztof Kozlowski wrote:
On 27/10/2022 12:17, Elliot Berman wrote:
Hi Rob,
On 10/26/2022 2:16 PM, Rob Herring wrote:
On Thu, Oct 13, 2022 at 6:59 PM Elliot Berman <quic_eberman@xxxxxxxxxxx> wrote:
On 10/12/2022 8:56 AM, Rob Herring wrote:
On Mon, Oct 10, 2022 at 05:08:29PM -0700, Elliot Berman wrote:
When Linux is booted as a guest under the Gunyah hypervisor, the Gunyah
Resource Manager applies a devicetree overlay describing the virtual
platform configuration of the guest VM, such as the message queue
capability IDs for communicating with the Resource Manager. This
information is not otherwise discoverable by a VM: the Gunyah hypervisor
core does not provide a direct interface to discover capability IDs nor
a way to communicate with RM without having already known the
corresponding message queue capability ID. Add the DT bindings that
Gunyah adheres for the hypervisor node and message queues.
Signed-off-by: Elliot Berman <quic_eberman@xxxxxxxxxxx>
---
.../bindings/firmware/gunyah-hypervisor.yaml | 87 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 88 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
diff --git a/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
new file mode 100644
index 000000000000..f0a14101e2fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/gunyah-hypervisor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gunyah Hypervisor
+
+maintainers:
+ - Murali Nalajala <quic_mnalajal@xxxxxxxxxxx>
+ - Elliot Berman <quic_eberman@xxxxxxxxxxx>
+
+description: |+
+ On systems which support devicetree, Gunyah generates and overlays a deviceetree overlay which
How you end up with the node (applying an overlay) is not relavent to
the binding.
+ describes the basic configuration of the hypervisor. Virtual machines use this information to determine
+ the capability IDs of the message queues used to communicate with the Gunyah Resource Manager.
Wrap at 80. That is the coding standard still though 100 is deemed
allowed. And yamllint only complains at 110 because I didn't care to fix
everyones lines over 100.
+ See also: https://github.com/quic/gunyah-resource-manager/blob/develop/src/vm_creation/dto_construct.c
+
+properties:
+ compatible:
+ items:
+ - const: gunyah-hypervisor-1.0
+ - const: gunyah-hypervisor
2 compatibles implies a difference between the 2. What's the difference?
Where does '1.0' come from?
There's no difference. I thought the convention was to have
device-specific compatible and the generic compatible. "device-specific"
here would be specific to version of Gunyah since it's software.
No, that's just what people do because "vendor,new-soc",
"vendor,old-soc" seems to bother them for some reason. At the end of
the day, it's just a string identifier that means something. If
there's no difference in that 'something', then there is no point in
having more than one string.
You only need something specific enough to discover the rest from the
firmware. When that changes, then you add a new compatible. Of course,
if you want existing OSs to work, then better not change the
compatible.
Thanks for the info, I'll drop the "-1.0" suffix.
You still did not answer from where does 1.0 come from... Compatibles
are usually expected to be specific.
The 1.0 comes from the Gunyah version. This is the same version returned
by "hyp_identify" hypercall.
