linux-kernel - Re: [PATCH v6 02/21] 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]

Message-ID: <CABb+yY2GA90RLazHZL7sLtC+ka-P8y6s00V2BVF4OMPTDi-rKg@mail.gmail.com>
Date:   Tue, 1 Nov 2022 16:58:36 -0500
From:   Jassi Brar <jassisinghbrar@...il.com>
To:     Elliot Berman <quic_eberman@...cinc.com>
Cc:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Rob Herring <robh+dt@...nel.org>,
        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>,
        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>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Amol Maheshwari <amahesh@....qualcomm.com>,
        Kalle Valo <kvalo@...nel.org>, devicetree@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 02/21] dt-bindings: Add binding for gunyah hypervisor

On Tue, Nov 1, 2022 at 3:35 PM Elliot Berman <quic_eberman@...cinc.com> wrote:
>
>
>
> On 11/1/2022 9:23 AM, Jassi Brar wrote:
> > On Mon, Oct 31, 2022 at 10:20 PM Elliot Berman <quic_eberman@...cinc.com> wrote:
> >>
> >> Hi Jassi,
> >>
> >> On 10/27/2022 7:33 PM, Jassi Brar wrote:
> >>   > On Wed, Oct 26, 2022 at 1:59 PM Elliot Berman
> >> <quic_eberman@...cinc.com> wrote:
> >>   > .....
> >>   >> +
> >>   >> +        gunyah-resource-mgr@0 {
> >>   >> +            compatible = "gunyah-resource-manager-1-0",
> >> "gunyah-resource-manager";
> >>   >> +            interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>, /* TX
> >> full IRQ */
> >>   >> +                         <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>; /* RX
> >> empty IRQ */
> >>   >> +            reg = <0x00000000 0x00000000>, <0x00000000 0x00000001>;
> >>   >> +                  /* TX, RX cap ids */
> >>   >> +        };
> >>   >>
> >>   > All these resources are used only by the mailbox controller driver.
> >>   > So, this should be the mailbox controller node, rather than the
> >>   > mailbox user.> One option is to load gunyah-resource-manager as a
> >> module that relies
> >>   > on the gunyah-mailbox provider. That would also avoid the "Allow
> >>   > direct registration to a channel" hack patch.
> >>
> >> A message queue to another guest VM wouldn't be known at boot time and
> >> thus couldn't be described on the devicetree.
> >>
> > I think you need to implement of_xlate() ... or please tell me what
> > exactly you need to specify in the dt.
>
> Dynamically created virtual machines can't be known on the dt, so there
> is nothing to specify in the DT. There couldn't be a devicetree node for
> the message queue client because that client is only exists once the VM
> is created by userspace.
>
The underlying "physical channel" is the synchronous SMC instruction,
which remains 1 irrespective of the number of mailbox instances
created.
So basically you are sharing one resource among users. Why doesn't the
RM request the "smc instruction" channel once and share it among
users?

-j