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_moisie...@epam.com> > > > > --- > > > > 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.
