linux-kernel - Re: [PATCH v5 02/13] dt-bindings: Add binding for gunyah hypervisor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Oct 2022 16:16:44 -0500
From:   Rob Herring <robh@...nel.org>
To:     Elliot Berman <quic_eberman@...cinc.com>
Cc:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Murali Nalajala <quic_mnalajal@...cinc.com>,
        Trilok Soni <quic_tsoni@...cinc.com>,
        Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
        Carl van Schaik <quic_cvanscha@...cinc.com>,
        Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Marc Zyngier <maz@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 02/13] dt-bindings: Add binding for gunyah hypervisor

On Thu, Oct 13, 2022 at 6:59 PM Elliot Berman <quic_eberman@...cinc.com> 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@...cinc.com>
> >> ---
> >>   .../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@...cinc.com>
> >> +  - Elliot Berman <quic_eberman@...cinc.com>
> >> +
> >> +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.

> We do similar for firmware in the qcom,scm bindings and following that
> principle.

Always poor examples to follow...

Rob