| Message ID | 20240910143411.178704-4-andrei.cherechesu@oss.nxp.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | xen/arm: Add support for S32CC platforms and LINFlexD UART | expand |
Hi, On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote: > From: Andrei Cherechesu <andrei.cherechesu@nxp.com> > > 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. 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? 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). Cheers, [1] https://lore.kernel.org/xen-devel/e9dadd96aa5b64b9232e10a083ce393af620adde.1639472078.git.oleksii_moisieiev@epam.com Cheers,
On Tue, 10 Sep 2024, Julien Grall wrote: > Hi, > > On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote: > > From: Andrei Cherechesu <andrei.cherechesu@nxp.com> > > > > 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. > > 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? > > 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). Hi Andrei, Julien, SCMI is very flexible and can be configured in a number of ways. In general, Julien has a point that typically forwarding to firmware all SCMI requests from Xen domains is not the desired behavior. An an example, imagine the case where device1 is assigned to domain1 and device2 is assigned to domain2. Now imagine that they both share a clock. Domain1 and domain2 could fight over the clock frequency settings using SCMI to change it, without being aware of each other activities. It is likely that the system would malfunction. If this kind of situations can happen on NXP S32CC platforms, then this patch might not be a good idea. As Julien suggested, you might want to have a look at Oleksii's approach. We could probably allow Dom0 to make all SCMI calls. If you think that is OK, you need to add a (is_hardware_domain(d)) check. On the other hand, if your SCMI server implementation has a way to prevent possible harmful activities from happening, or maybe all clocks are fixed-clocks so there are actually no SCMI operations to control the clocks, then it could be possible that this patch might be fine. I admit it is unlikely because there is a number of ways SCMI could be used by one domain to hurt another domain. Can you please give us a brief overview on how SCMI is expected to work on NXP S32CC?
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@nxp.com> >>> >>> 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/ > > Hi Andrei, Julien, > > SCMI is very flexible and can be configured in a number of ways. In > general, Julien has a point that typically forwarding to firmware all > SCMI requests from Xen domains is not the desired behavior. > > An an example, imagine the case where device1 is assigned to domain1 and > device2 is assigned to domain2. Now imagine that they both share a > clock. Domain1 and domain2 could fight over the clock frequency settings > using SCMI to change it, without being aware of each other activities. > It is likely that the system would malfunction. I completely agree and we are aware of the possible resource contention. Another (simpler?) scenariowhere access control is needed, besides the one you described, is when Domain1 would directly try to perform some requests for some resources that affect Device2 (owned by Domain2). If Domain1 knows the clock IDs used by Device2, for example, without any access control it could perform a SCMI clock request affecting Device2's clocks, which should be out of his control. > > If this kind of situations can happen on NXP S32CC platforms, then this > patch might not be a good idea. As Julien suggested, you might want to > have a look at Oleksii's approach. We could probably allow Dom0 to make > all SCMI calls. If you think that is OK, you need to add a > (is_hardware_domain(d)) check. > On the other hand, if your SCMI server implementation has a way to > prevent possible harmful activities from happening, or maybe all clocks > are fixed-clocks so there are actually no SCMI operations to control the > clocks, then it could be possible that this patch might be fine. I admit > it is unlikely because there is a number of ways SCMI could be used by > one domain to hurt another domain. > > Can you please give us a brief overview on how SCMI is expected to work > on NXP S32CC? Well, we normally rely on most SCMI protocols to access system-level resources from agents: Base, Power Domain, System Power, Performance Domain, Clock, Reset Domain. Linux jumps to EL3 via SMC carrying an SCMI message, and FW running at EL3 decides how to handle it. Basically, Linux cannot directly control most system-level resources. With Xen, we currently don't allow unprivileged Domains to do SCMI requests. The SMCs are of course trapped at EL2 and that's why we enabled forwarding to EL3 without any access control, knowing it shouldn't break anything, and to let everything function as normal. In some passthrough scenarios the unprivileged domains rely on settings already made by firmware (for clocks, pins, etc) that their assigned devices require, and in DT we replace them with e.g. fixed-clock for clocks. An "is_hardware_domain(d)" check should be enough for the moment to harden the code, but I agree that this should not be something platform-specific in the future, and the handling must be done in a generic way. So I would proceed with this approach for this patch series, if that's ok for you, and I will also take a look at Oleksii's approach. Regards, Andrei C
On Thu, 11 Sep 2024, Andrei Cherechesu 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@nxp.com> > > 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/ > > > Hi Andrei, Julien, > > SCMI is very flexible and can be configured in a number of ways. In > general, Julien has a point that typically forwarding to firmware all > SCMI requests from Xen domains is not the desired behavior. > > An an example, imagine the case where device1 is assigned to domain1 and > device2 is assigned to domain2. Now imagine that they both share a > clock. Domain1 and domain2 could fight over the clock frequency settings > using SCMI to change it, without being aware of each other activities. > It is likely that the system would malfunction. > > I completely agree and we are aware of the possible resource contention. Another (simpler?) scenario where access control is needed, > besides the one you described, is when Domain1 would directly try to perform some requests for some resources that affect Device2 (owned by > Domain2). If Domain1 knows the clock IDs used by Device2, for example, without any access control it could perform a SCMI clock request > affecting Device2's clocks, which should be out of his control. > > > If this kind of situations can happen on NXP S32CC platforms, then this > patch might not be a good idea. As Julien suggested, you might want to > have a look at Oleksii's approach. We could probably allow Dom0 to make > all SCMI calls. If you think that is OK, you need to add a > (is_hardware_domain(d)) check. > > On the other hand, if your SCMI server implementation has a way to > prevent possible harmful activities from happening, or maybe all clocks > are fixed-clocks so there are actually no SCMI operations to control the > clocks, then it could be possible that this patch might be fine. I admit > it is unlikely because there is a number of ways SCMI could be used by > one domain to hurt another domain. > > Can you please give us a brief overview on how SCMI is expected to work > on NXP S32CC? > > Well, we normally rely on most SCMI protocols to access system-level resources from agents: Base, Power Domain, System Power, Performance > Domain, Clock, Reset Domain. Linux jumps to EL3 via SMC carrying an SCMI message, and FW running at EL3 decides how to handle it. > Basically, Linux cannot directly control most system-level resources. > > With Xen, we currently don't allow unprivileged Domains to do SCMI requests. The SMCs are of course trapped at EL2 and that's why we > enabled forwarding to EL3 without any access control, knowing it shouldn't break anything, and to let everything function as normal. In > some passthrough scenarios the unprivileged domains rely on settings already made by firmware (for clocks, pins, etc) that their assigned > devices require, and in DT we replace them with e.g. fixed-clock for clocks. > > An "is_hardware_domain(d)" check should be enough for the moment to harden the code, but I agree that this should not be something > platform-specific in the future, and the handling must be done in a generic way. > So I would proceed with this approach for this patch series, if that's ok for you, and I will also take a look at Oleksii's approach. I know how hard is to solve this properly and it might take months. I wouldn't want to stop Xen from working on NXP S32CC until a proper SCMI solution is found. For now, I would say to add the "is_hardware_domain(d)" check. Julien, do you also agree?
Hi Andrei, > On 11 Sep 2024, at 23:05, Andrei Cherechesu <andrei.cherechesu@oss.nxp.com> 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@nxp.com> >>>> >>>> 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. Cheers Bertrand >> >> Hi Andrei, Julien, >> >> SCMI is very flexible and can be configured in a number of ways. In >> general, Julien has a point that typically forwarding to firmware all >> SCMI requests from Xen domains is not the desired behavior. >> >> An an example, imagine the case where device1 is assigned to domain1 and >> device2 is assigned to domain2. Now imagine that they both share a >> clock. Domain1 and domain2 could fight over the clock frequency settings >> using SCMI to change it, without being aware of each other activities. >> It is likely that the system would malfunction. > I completely agree and we are aware of the possible resource contention. Another (simpler?) scenario where access control is needed, besides the one you described, is when Domain1 would directly try to perform some requests for some resources that affect Device2 (owned by Domain2). If Domain1 knows the clock IDs used by Device2, for example, without any access control it could perform a SCMI clock request affecting Device2's clocks, which should be out of his control. >> >> If this kind of situations can happen on NXP S32CC platforms, then this >> patch might not be a good idea. As Julien suggested, you might want to >> have a look at Oleksii's approach. We could probably allow Dom0 to make >> all SCMI calls. If you think that is OK, you need to add a >> (is_hardware_domain(d)) check. >> On the other hand, if your SCMI server implementation has a way to >> prevent possible harmful activities from happening, or maybe all clocks >> are fixed-clocks so there are actually no SCMI operations to control the >> clocks, then it could be possible that this patch might be fine. I admit >> it is unlikely because there is a number of ways SCMI could be used by >> one domain to hurt another domain. >> >> Can you please give us a brief overview on how SCMI is expected to work >> on NXP S32CC? > Well, we normally rely on most SCMI protocols to access system-level resources from agents: Base, Power Domain, System Power, Performance Domain, Clock, Reset Domain. Linux jumps to EL3 via SMC carrying an SCMI message, and FW running at EL3 decides how to handle it. Basically, Linux cannot directly control most system-level resources. > > With Xen, we currently don't allow unprivileged Domains to do SCMI requests. The SMCs are of course trapped at EL2 and that's why we enabled forwarding to EL3 without any access control, knowing it shouldn't break anything, and to let everything function as normal. In some passthrough scenarios the unprivileged domains rely on settings already made by firmware (for clocks, pins, etc) that their assigned devices require, and in DT we replace them with e.g. fixed-clock for clocks. > > An "is_hardware_domain(d)" check should be enough for the moment to harden the code, but I agree that this should not be something platform-specific in the future, and the handling must be done in a generic way. > So I would proceed with this approach for this patch series, if that's ok for you, and I will also take a look at Oleksii's approach. > > Regards, > Andrei C > > > >
On Thu, 12 Sep 2024, Bertrand Marquis wrote: > Hi Andrei, > > > On 11 Sep 2024, at 23:05, Andrei Cherechesu <andrei.cherechesu@oss.nxp.com> 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@nxp.com> > >>>> > >>>> 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
Hi, On 12/09/2024 23:44, Stefano Stabellini wrote: > On Thu, 12 Sep 2024, Bertrand Marquis wrote: >> Hi Andrei, >> >>> On 11 Sep 2024, at 23:05, Andrei Cherechesu <andrei.cherechesu@oss.nxp.com> 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@nxp.com> >>>>>> >>>>>> 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 I am open to go this way. But I would like the commit message to contain some details on whether this will always work fine for dom0 (this would tell whether the feature can be supported or needs to be in experimental/tech preview). At least my main concern is anything to do with RAM. On Matrix, Bertrand suggested that none of the messages should contain addresses. What about the transport? Is it using buffer? If so, are they fixed? Brief looking at Linux, there are multiple DT compatible. IIUC, we would only support "arm,scmi-smc" with the implementation. If so, maybe we should check the DT. Cheers,
Hi, On 13/09/2024 08:43, Julien Grall wrote: > On 12/09/2024 23:44, Stefano Stabellini wrote: >> On Thu, 12 Sep 2024, Bertrand Marquis wrote: >>> Hi Andrei, >>> >>>> On 11 Sep 2024, at 23:05, Andrei Cherechesu >>>> <andrei.cherechesu@oss.nxp.com> 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@nxp.com> >>>>>>> >>>>>>> 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 > I am open to go this way. But I would like the commit message to contain > some details on whether this will always work fine for dom0 (this would > tell whether the feature can be supported or needs to be in > experimental/tech preview). > > At least my main concern is anything to do with RAM. On Matrix, Bertrand > suggested that none of the messages should contain addresses. What about > the transport? Is it using buffer? If so, are they fixed? > > Brief looking at Linux, there are multiple DT compatible. IIUC, we would > only support "arm,scmi-smc" with the implementation. If so, maybe we > should check the DT. Some clarifications as I was asked on Matrix. The issue described in this patch is not specific to SCMI. So I think the SCMI trapping & forward should be part of common code. If it we are not sure whether it is safe, then it should be protected by CONFIG_EXPERT or CONFIG_UNSUPPORTED. I hope this clarifies what I would like. Not sure if the others agree though. Cheers,
On Mon, 16 Sep 2024, Julien Grall wrote: > On 13/09/2024 08:43, Julien Grall wrote: > > On 12/09/2024 23:44, Stefano Stabellini wrote: > > > On Thu, 12 Sep 2024, Bertrand Marquis wrote: > > > > Hi Andrei, > > > > > > > > > On 11 Sep 2024, at 23:05, Andrei Cherechesu > > > > > <andrei.cherechesu@oss.nxp.com> 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@nxp.com> > > > > > > > > > > > > > > > > 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 > > I am open to go this way. But I would like the commit message to contain > > some details on whether this will always work fine for dom0 (this would tell > > whether the feature can be supported or needs to be in experimental/tech > > preview). > > > > At least my main concern is anything to do with RAM. On Matrix, Bertrand > > suggested that none of the messages should contain addresses. What about the > > transport? Is it using buffer? If so, are they fixed? > > > > Brief looking at Linux, there are multiple DT compatible. IIUC, we would > > only support "arm,scmi-smc" with the implementation. If so, maybe we should > > check the DT. > > Some clarifications as I was asked on Matrix. The issue described in this > patch is not specific to SCMI. So I think the SCMI trapping & forward should > be part of common code. If it we are not sure whether it is safe, then it > should be protected by CONFIG_EXPERT or CONFIG_UNSUPPORTED. > > I hope this clarifies what I would like. Not sure if the others agree though. I think it is a good idea to make the SCMI trapping and forwarding in common code. I am fine with that. I think it is OK to enable it by default without CONFIG_EXPERT. I am OK with or without using CONFIG_UNSUPPORTED. I am happy either way. Thanks Julien, good suggestion.
diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig index 76f7e76b1b..310b35122a 100644 --- a/xen/arch/arm/platforms/Kconfig +++ b/xen/arch/arm/platforms/Kconfig @@ -37,6 +37,13 @@ config MPSOC help Enable all the required drivers for Xilinx Ultrascale+ MPSoC +config S32CC + bool "NXP S32CC platforms support" + depends on ARM_64 + select HAS_LINFLEX + help + Enable all the required drivers for NXP S32CC platforms + config NO_PLAT bool "No Platforms" help @@ -56,3 +63,6 @@ config MPSOC_PLATFORM bool default (ALL64_PLAT || MPSOC) +config S32CC_PLATFORM + bool + default (ALL64_PLAT || S32CC) diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index bec6e55d1f..2c304b964d 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -10,5 +10,6 @@ obj-$(CONFIG_ALL64_PLAT) += thunderx.o obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o obj-$(CONFIG_ALL64_PLAT) += imx8qm.o +obj-$(CONFIG_S32CC_PLATFORM) += s32cc.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o diff --git a/xen/arch/arm/platforms/s32cc.c b/xen/arch/arm/platforms/s32cc.c new file mode 100644 index 0000000000..f262673b09 --- /dev/null +++ b/xen/arch/arm/platforms/s32cc.c @@ -0,0 +1,84 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * xen/arch/arm/platforms/s32cc.c + * + * NXP S32CC Platform-specific settings + * + * Andrei Cherechesu <andrei.cherechesu@nxp.com> + * Copyright 2021-2024 NXP + */ + +#include <asm/platform.h> +#include <asm/regs.h> +#include <asm/smccc.h> + +#define S32CC_SMC_SCMI_FN 0xFE +#define S32CC_SMCCC_FID(fn) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ + ARM_SMCCC_CONV_64, \ + ARM_SMCCC_OWNER_SIP, \ + fn) + +static bool s32cc_smc(struct cpu_user_regs *regs) +{ + struct arm_smccc_res res; + uint32_t fid = get_user_reg(regs, 0); + + /* Check for SMCCC 1.1 availability */ + if ( !cpus_have_const_cap(ARM_SMCCC_1_1) ) + { + printk_once(XENLOG_WARNING + "S32CC: No SMCCC 1.1 support, disabling fw calls."); + return false; + } + + switch ( fid ) + { + /* SCMI */ + case S32CC_SMCCC_FID(S32CC_SMC_SCMI_FN): + goto forward_to_fw; + + default: + printk_once(XENLOG_WARNING "S32CC: Unhandled SMC call: %u\n", fid); + return false; + } + +forward_to_fw: + arm_smccc_1_1_smc(fid, + get_user_reg(regs, 1), + get_user_reg(regs, 2), + get_user_reg(regs, 3), + get_user_reg(regs, 4), + get_user_reg(regs, 5), + get_user_reg(regs, 6), + get_user_reg(regs, 7), + &res); + + set_user_reg(regs, 0, res.a0); + set_user_reg(regs, 1, res.a1); + set_user_reg(regs, 2, res.a2); + set_user_reg(regs, 3, res.a3); + + return true; +} + +static const char * const s32cc_dt_compat[] __initconst = +{ + "nxp,s32g2", + "nxp,s32g3", + "nxp,s32r45", + NULL +}; + +PLATFORM_START(s32cc, "NXP S32CC") + .compatible = s32cc_dt_compat, + .smc = s32cc_smc, +PLATFORM_END + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ \ No newline at end of file