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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

Hi Stefano,

On Wed, Dec 22, 2021 at 06:23:33PM -0800, Stefano Stabellini wrote:
> 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.

Thank you for suggestions. I will use this approach in v2.