[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v1 4/5] tools/arm: add "scmi_smc" option to xl.cfg



On Wed, 22 Dec 2021, Oleksii Moisieiev wrote:
> On Mon, Dec 20, 2021 at 04:54:25PM -0800, Stefano Stabellini wrote:
> > On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> > > This enumeration sets SCI type for the domain. Currently there is
> > > two possible options: either 'none' or 'scmi_smc'.
> > > 
> > > 'none' is the default value and it disables SCI support at all.
> > > 
> > > 'scmi_smc' enables access to the Firmware from the domains using SCMI
> > > protocol and SMC as transport.
> > > 
> > > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>
> > > ---
> > >  docs/man/xl.cfg.5.pod.in         | 22 ++++++++++++++++++++++
> > >  tools/include/libxl.h            |  5 +++++
> > >  tools/libs/light/libxl_types.idl |  6 ++++++
> > >  tools/xl/xl_parse.c              |  9 +++++++++
> > >  4 files changed, 42 insertions(+)
> > > 
> > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > > index b98d161398..92d0593875 100644
> > > --- a/docs/man/xl.cfg.5.pod.in
> > > +++ b/docs/man/xl.cfg.5.pod.in
> > > @@ -1614,6 +1614,28 @@ This feature is a B<technology preview>.
> > >  
> > >  =back
> > >  
> > > +=item B<sci="STRING">
> > > +
> > > +B<Arm only> Set SCI type for the guest. SCI is System Control Protocol -
> > > +allows domain to manage various functions that are provided by HW 
> > > platform.
> > > +
> > > +=over 4
> > > +
> > > +=item B<none>
> > > +
> > > +Don't allow guest to use SCI if present on the platform. This is the 
> > > default
> > > +value.
> > > +
> > > +=item B<scmi_smc>
> > > +
> > > +Enables SCMI-SMC support for the guest. SCMI is System Control Management
> > > +Inferface - allows domain to manage various functions that are provided 
> > > by HW
> > > +platform, such as clocks, resets and power-domains. Xen will mediate 
> > > access to
> > > +clocks, power-domains and resets between Domains and ATF. Disabled by 
> > > default.
> > > +SMC is used as transport.
> > 
> > Would it make sense to actually enable SCMI-SMC support for the guest by
> > default if the guest has any devices directly assigned?
> 
> Hi Stefano,
> 
> Previously we discussed with Oleksandr about introducing new dom.cfg
> parameter, such as scidev[] lists all sci related nodes, which will help to
> avoid extra domctl calls.

The concerning part is (too much) information the user needs to provide
in device tree or dom.cfg. We can be flexible with the number of extra
domctl calls, but of course it would be good to avoid them too.


> But there is still a question how mediator types should be set for
> different domains? I know currently system supports only one mediator
> type, but different implementation should be also possible.

I think it is fine to have an option sci="scmi_smc" in dom.cfg, that is
not a problem. The issue is a detailed list of SCMI IDs or a second list
of device tree paths, because those are far harder to write correctly.


> For example, if we have to start dom0 and domd using scmi_mailbox
> mediator and domU using scmi_smc, because our system supports only 2
> mailboxes.

Yeah that's fine, it could be done with the sci option you are
suggesting.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.