Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 24 Feb 2022 14:51:42 -0800 (PST)
From:   Stefano Stabellini <sstabellini@kernel.org>
To:     Sudeep Holla <sudeep.holla@arm.com>
cc:     Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>,
        Cristian Marussi <cristian.marussi@arm.com>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Souvik Chakravarty <Souvik.Chakravarty@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/1] dt-bindings: arm: Add scmi_devid paramter for
In-Reply-To: <20220224115443.fwhczfvm3cfwoim7@bogus>
Message-ID: <alpine.DEB.2.22.394.2202241424110.239973@ubuntu-linux-20-04-desktop>
References: <cover.1645460043.git.oleksii_moisieiev@epam.com> <20220222110003.GC21915@e120937-lin> <20220222160637.yn6pru4nfgwih23j@bogus> <20220222171549.GA2194063@EPUAKYIW015D> <20220224115443.fwhczfvm3cfwoim7@bogus>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Thu, 24 Feb 2022, Sudeep Holla wrote:
> On Tue, Feb 22, 2022 at 05:15:49PM +0000, Oleksii Moisieiev wrote:
> > Hi Sudeep,
> > 
> > On Tue, Feb 22, 2022 at 04:06:37PM +0000, Sudeep Holla wrote:
> > > Hi Oleksii,
> > > 
> > > My initial feedback on this. And thanks Cristian for making it so easy as
> > > you have covered most of the things in depth(which I might have not done
> > > myself that well)
> > > 
> > > On Tue, Feb 22, 2022 at 11:00:03AM +0000, Cristian Marussi wrote:
> > > > On Mon, Feb 21, 2022 at 05:26:46PM +0000, Oleksii Moisieiev wrote:
> > > > > Introducing new parameter called scmi_devid to the device-tree bindings.
> > > > > This parameter should be set for the device nodes, which has
> > > > > clocks/power-domains/resets working through SCMI.
> > > 
> > > I prefer you had given more details on your usage model here instead of
> > > pointing to the other Xen thread as it helps for someone without much
> > > background on Xen or your use-case to review this.
> > > 
> > Let me describe the process in few words:
> > We implemented a new feature, called SCI-mediator in Xen.
> > The proposed implementation allows Guests to communicate with the Firmware using SCMI
> > protocol with SMC as a transport. Other implementation are also
> > possible, such as SCMI-Mailbox, SCPI-mailbox etc.
> > 
> > In this feature Xen is the Trusted Agent, which receives the following
> > information in Xen device-tree:
> > 1) All channels should be described, each channel defined as
> > arm,scmi-shmem node;
> > 2) Scmi node arm,scmi-smc with protocols description;
> 
> Sounds good so far.
> 
> > 3) scmi-devid should be set in nodes, which works through SCMI.
> >
> 
> Why is this needed for Guest OS, you need not populate this if Guest OS
> is not required to use it, right ? If it is needed just by Xen hypervisor,
> lets talk about that and why it is bad idea to mix that with general
> SCMI bindings.

I'll try to help Oleksii by answering here, I hope I am not off the mark
:-)

I think Sudeep is right, scmi-devid is not needed by the guest OS.

The host device tree is a more interesting discussion. As the host
device tree is meant to be generic and not tied to a specific version of
Linux, it should fully describe the SCMI interface available. If the
device tree is provided to a Trusted Agent, then it should also have the
scmi-devid information, right?


> > On start Xen inits itself as trusted agent and requests agent
> > configuration by using BASE_DISCOVER_AGENT message. This message is sent
> > to each configured channel to get agent_id
> > 
> > On Domain creation stage Xen will do the following steps:
> > 1) Assign channel to the Guest and map channel address to the Domain
> > address. For the Domain this address should be the same;
> > 2) Generate arm,scmi-shmem and arm,scmi-smc nodes if needed for Guest
> > device-tree (the device-tree which should be passed to the Guest);
> > 3) Process devices, which are passed through to this Guest and set
> > BASE_SET_DEVICE_PERMISSIONS for the scmi-devid, received from the
> > device-node;
> >
> 
> I am confused here. So the Xen knows which devices are assigned to each
> Guest OS but doesn't know device ID for them, but relies on the device
> tree node ?

Which devices go to which guest OS is a user-provided configuration. For
instance, a user can say: "assing /amba/ethernet@ff0e0000 to dom1". This
is normal and not related to SCMI: when a user configures a static
partitioning system, they decide which resources belong to which domain.

So Xen is told that /amba/ethernet@ff0e0000 is supposed to go to dom1.
Xen proceeds to map memory and interrupts corresponding to
/amba/ethernet@ff0e0000 to dom1. So far so good. What about SCMI?

In Oleksii's design, Xen is going to assign one of the available SCMI
channels to dom1 and restrict its permission to only
/amba/ethernet@ff0e0000. To do that, Xen needs to know the scmi-devid of
/amba/ethernet@ff0e0000. As far as I can tell there is nothing
Xen-specific in this activitity, that's why I asked Oleksii to reach out
to the upstream device tree community to improve the generic bindings
for everyone's benefits.