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

[Julien Grall <julien@xxxxxxx>]

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.
> 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?
> 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 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?

> 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?

Cheers,

--
Julien Grall