From: Stefano Stabellini <sstabellini@kernel.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
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>,
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
Date: Thu, 24 Feb 2022 15:34:01 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2202241531111.239973@ubuntu-linux-20-04-desktop> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2202241424110.239973@ubuntu-linux-20-04-desktop>
On Thu, 24 Feb 2022, Stefano Stabellini wrote:
> 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.
Let's leave Linux and Xen aside for the moment. What are other possible
Trusted Agents? (Maybe TF-A?) How do they get the scmi-devid? It looks
like it was supposed to come from device tree but nobody got around to
adding it to the binding because it is not used by Linux?
next prev parent reply other threads:[~2022-02-24 23:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-21 17:26 [RFC PATCH 0/1] dt-bindings: arm: Add scmi_devid paramter for Oleksii Moisieiev
2022-02-21 17:26 ` [RFC PATCH 1/1] dt-bindings: arm: Add scmi_devid property description for SCMI Oleksii Moisieiev
2022-02-22 14:22 ` Rob Herring
2022-02-22 14:51 ` Oleksii Moisieiev
2022-02-22 18:25 ` Rob Herring
2022-02-21 21:01 ` [RFC PATCH 0/1] dt-bindings: arm: Add scmi_devid paramter for Krzysztof Kozlowski
2022-02-21 21:39 ` Oleksii Moisieiev
2022-02-22 8:06 ` Krzysztof Kozlowski
2022-02-22 8:55 ` Oleksii Moisieiev
2022-02-22 9:27 ` Krzysztof Kozlowski
2022-02-22 10:30 ` Oleksii Moisieiev
2022-02-22 11:16 ` Krzysztof Kozlowski
2022-02-22 13:54 ` Oleksii Moisieiev
2022-02-22 16:14 ` Sudeep Holla
2022-02-22 17:34 ` Oleksii Moisieiev
2022-02-24 2:51 ` Stefano Stabellini
2022-02-24 9:32 ` Cristian Marussi
2022-02-24 22:22 ` Stefano Stabellini
2022-03-01 14:55 ` Oleksii Moisieiev
2022-03-04 11:21 ` Sudeep Holla
2022-03-04 11:18 ` Sudeep Holla
2022-02-22 11:00 ` Cristian Marussi
2022-02-22 13:51 ` Oleksii Moisieiev
2022-02-22 16:06 ` Sudeep Holla
2022-02-22 17:15 ` Oleksii Moisieiev
2022-02-24 11:54 ` Sudeep Holla
2022-02-24 22:51 ` Stefano Stabellini
2022-02-24 23:34 ` Stefano Stabellini [this message]
2022-03-04 11:12 ` Sudeep Holla
2022-03-05 0:45 ` Stefano Stabellini
2022-04-29 21:46 ` Rob Herring
2022-03-01 16:10 ` Oleksii Moisieiev
2022-03-01 16:05 ` Oleksii Moisieiev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.22.394.2202241531111.239973@ubuntu-linux-20-04-desktop \
--to=sstabellini@kernel.org \
--cc=Oleksii_Moisieiev@epam.com \
--cc=Souvik.Chakravarty@arm.com \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).