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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

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. Those
interfaces can be different than the interface Xen uses to connect to SCP.
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
Where Xen knows how to convert message from yyy protocol to scmi protocol.

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.

What do you think about that?

Best regards,
Oleksii