Re: [PATCH v1 3/5] xen/arm: platforms: Add NXP S32CC platform code

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 12 Sep 2024, Bertrand Marquis wrote:
> Hi Andrei,
> 
> > On 11 Sep 2024, at 23:05, Andrei Cherechesu <andrei.cherechesu@xxxxxxxxxxx> 
> > wrote:
> > 
> > Hi Julien, Stefano, 
> > On 11/09/2024 08:19, Stefano Stabellini wrote:
> >> On Tue, 10 Sep 2024, Julien Grall wrote:
> >> 
> >>> Hi,
> >>> 
> >>> On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
> >>> 
> >>>> From: Andrei Cherechesu <andrei.cherechesu@xxxxxxx>
> >>>> 
> >>>> Added support for NXP S32CC platforms (S32G2, S32G3, S32R45),
> >>>> which need SCMI over SMC calls forwarded to the firmware
> >>>> running at EL3 (TF-A). Linux relies on the SCMI Platform
> >>>> for system services such as clocking, reset, etc.
> >>>> 
> >>> Is it SMCI as in the Arm spec? If so, this should not be platform 
> >>> specific.
> > Yes, it is SCMI as defined by Arm. I agree it shouldn't be platform 
> > specific.
> >> 
> >>> 
> >>> Furthermore, I was under the impression that we can't blindly forward
> >>> everything from a domain to the firmware. While it might be okayish for 
> >>> dom0,
> >>> you also seem to give access to all the domains on the system is it 
> >>> intended?
> > In our case, only Dom0 has access to the SCMI mailbox. Hence, the other 
> > unprivileged domains are not aware of SCMI and do not make any SCMI 
> > requests to FW.
> >> 
> >>> 
> >>> Anyway, there is a series on the ML to add a mediator for SCMI in Xen (see
> >>> [1]). I think it would be preferable to focus on getting it merged as it 
> >>> would
> >>> 
> >>> benefit everyone and increase the security posture (we could restrict 
> >>> access).
> > I also asked a few months ago on the ML in a virtio related thread if there 
> > are any updates regarding 
> > SCMI awareness for Xen and guests, then Stefano CCed Bertrand, but he did 
> > not comment [0].
> > I'm curious why the SCMI mediator patch series did not progress.
> > [0] 
> > https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2401111627360.3675@ubuntu-linux-20-04-desktop/
> 
> Sorry it seems i missed that one.
> 
> There are several initiatives ongoing to investigate the global problem of 
> clock handling and more specifically
> SCMI "sharing".
> The SCMI protocol contains some features to have virtual channels and the 
> question is how to make a transport
> that is hypervisor agnostic to prevent to require the hypervisors to have to 
> "decode" SCMI messages.
> 
> Virtio-scmi is not really used for clock management per say at the moment and 
> more specifically I do not
> think it is a good solution to manage clocks of non virtio devices.
> 
> In Soafee and in Linaro people are looking at using FF-A as a tansport for 
> SCMI.
> The idea would be that the hypervisor is configuring the virtual SCMI 
> channels using FF-A as a transport
> and then VMs are using FF-A to communicate with an SCMI server (probably 
> sitting in secure world, at
> least as a proxy). This is an investigation for now.
> 
> Requiring Xen to act as a mediator is also a solution but might require a lot 
> of platform specific code
> which i think we should prevent.
> 
> For now having a solution in Xen where SCMI calls through SMC are only 
> allowed by Dom0 is the only
> short term solution I think.

+1