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.
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?
Cheers,
--
Julien Grall
