Re: [RFC v1 3/5] xen/arm: introduce SCMI-SMC mediator driver

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

On Mon, Jan 03, 2022 at 02:23:01PM +0000, Julien Grall wrote:
> Hi,
> 
> On 24/12/2021 16:49, Oleksii Moisieiev wrote:
> > On Fri, Dec 24, 2021 at 03:28:56PM +0100, Julien Grall wrote:
> > > On 24/12/2021 14:59, Oleksii Moisieiev wrote:
> > > > Hi Julien,
> > > 
> > > Hello,
> > > 
> > > > On Fri, Dec 24, 2021 at 02:29:13PM +0100, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 24/12/2021 01:16, Stefano Stabellini wrote:
> > > > > > > One more question: As you probably seen - Jan had a complains 
> > > > > > > about SCI
> > > > > > > term. He said SCI is ambiguous with ACPI's System
> > > > > > > Control Interrupt.
> > > > > > 
> > > > > > I see his point. As a term I see "SCMI" often and sometimes "SCPI" 
> > > > > > but
> > > > > > "SCI" is the first time I saw it with this patch series.
> > > > > > 
> > > > > > 
> > > > > > > I think of using SC (as System Control) instead. What do you think
> > > > > > > about it?
> > > > > > 
> > > > > > Yeah, I am not great at naming things but maybe "ARM_SCI"?  "SC" 
> > > > > > alone
> > > > > > doesn't give me enough context to guess what it is.
> > > > > 
> > > > > I might be missing some context. Why are naming everything SCI rather 
> > > > > than
> > > > > SMCI?
> > > > 
> > > > Because we're expecting other interfaces and transport to be
> > > > implemented, such as for example:
> > > > scmi_mailbox, scpi_smc, scpi_mailbox, ti_sci_smc etc.
> > > 
> > > Oh, now that explain why there is a layer of indirection in Xen. It wasn't
> > > very clear from the cover letter why it was present.
> > > 
> > Please see below.
> > > > 
> > > > > 
> > > > > > 
> > > > > > Or we could broaden the scope and call it "firmware_interface"?
> > > > > How would this be used? Will it be a list of interface that will be 
> > > > > exposed
> > > > > to the guest?
> > > > > 
> > > > 
> > > > The idea is to set mediator type for each Domain, so for example Xen can
> > > > use scmi_mailbox to communicate with SCP, Dom0 and DomD are also using
> > > > scmi_mailbox, but DomU using scmi_smc mediator because we have only 3
> > > > mailboxes in system. This is not implemented yet, right now, we are
> > > > introducing only scmi_smc support. In future, multiple mediator support
> > > > can be added to Xen.
> > > 
> > > Ok. So will there be only one interface at the time for a given domain. Is
> > > that correct?
> > > 
> > Correct. The idea is that we provice only one interface to the Domain,
> > so different domains can use different protocols and transport
> 
> I think this is similar to TEE mediator. Specifying in the guest
> configuration the TEE protocol (e.g. OP-TEE) allows to sanity check what the
> guest wants match the host. However, I am not convinced there is a need to
> expose different protocols for domains running on the same platform.
> 

Yes. You're right, I based on TEE mediator during implementation.
Please see below my thoughts about different protocols and transports.
> > Those
> > interfaces can be different than the interface Xen uses to connect to SCP.
> 
> I can understand how this looks appealing. However, it may not always be
> possible to convert the guest protocol to the host protocol. And even if it
> is possible, it is increasing the complexity and risk.
> 
> > This allows us to vary the configuration.
> > So for example:
> > Let's take system, that support only 2 mailboxes and communication with
> > SCP can use only mailboxes as transport. We intent to use scmi protocol
> > to manage HW. In this case we use 2 mailboxes for Xen-> SCP
> > communication, and for Dom0 -> Xen.
> > Domu can be configured to use
> > scmi_smc, so the communication should be the following:
> > DomU --smc--> Xen -mailbox--> SCP Firmware.
> > Let's say we want to add DomainX with OS XXX, which using yyy protocol
> > with zzz transport. Then we can configure DomX wuth yyy_zzz mediator, so
> > the communication will be the following:
> > DomX --yyy--> Xen -mailbox--> SCP Firmware
> 
> I am a bit confused with your example here. From my understanding, I would
> say 'smc' is the transport. But in your example above, you suggest this is
> the protocol. What did I miss?

Sorry, that's my fault. I merged 2 exapmles in 1, in which the first example
shows different transports and the second one shows different protocols.

The first expample describes the use-case when we have firmware, using
mailboxes as transport, but the system we have has number of Domains >
than number of the mailboxes.
Let's say Firmware and all Domains are using scmi protocol.
In this case I see 2 possible configurations:

1) Firmware and some Domains are using mailbox as transport, other
Domains, when all mailboxes are occupied, are using smc as transport.
Xen will be responsible to receive smc message and send request to
Firmware using mailbox and vice versa.

2) Firmware using mailbox to communicate with Xen, all Domains are using
smc. In this case only one mailbox will be used.

Number 2 looks better from my standpoint. In that case we have scmi_smc
mediator, which exposes smc transport to domains and uses mailbox to
communicate with Firmware.

The second part is that we can change protocol when it's simple and
safe. But now I see that this is not a good Idea to make Xen responsible
for protocol converting.

> 
> > Where Xen knows how to convert message from yyy protocol to scmi protocol
> 
> As I wrote above, when possible, converting protocol could be complex and
> risky. So do you have a concrete use case for that?
> 
> That said, changing the transport (e.g. smc <-> mailbox) would make more
> sense to me.
> 

I think you're right.

> > 
> > I considered the alternative way, when we can configure domain with
> > several mediators, so each Domain can be configured to use, for example,
> > scmi_smc for power-domains and scpi_smc for clocks and resets. But I
> > don't see real use-cases for this configuration.
> 
> Do you mean a platform using both or exposing both to the guest?
> 

Yes, that's the alternative way I see. Similar to linux kernel, where
you are allowed to use for example scmi for clocks and scpi for resets.
I don't see the real use-cases for this config, but Xen can follow Linux
kernel configuration approach and allow to register 2 mediators: one for
scmi_smc and one for scpi_smc.
In this case Domain configuration will look like this:
sci = [
    "scmi_smc",
    "scpi_smc",
    ];

So both scmi_smc and scpi_smc mediators are exposing protocols to the
domains and communicating with Firmware.
Current implementation supports only 1 mediator, but in future I think
we should consider the posibility of having several mediators.
Where each mediator has it's own channel (transport+protocol) to
Firmware and exposes transport+protocol to the guests.

> > 
> > What do you think about that?
> So I am a bit unsure how "firmware_interface" would be specified. IMO, the
> user should only specificy which interface the guest will use (e.g. SCMI via
> SMC) even if the host end up to use a different transport (e.g. SCMI via
> mailbox). IOW, the option would not tell how to convert it.
> 
> Is it what you had in mind?
> 

Yes. That's what I mean.
firmware_interface can be specified in xen Device-tree. Different SCI
mediators can be implemented and added to the device-tree. Each mediator has 
channel (protocol +
transports) to the Firmware and exposes protocol + transport to the guests.
Protocol to the Firmware should be the same as exposed protocol,
transport may differ and is implementation specific.


Best regards,
Oleksii.