Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi Stefano, On Mon, Feb 14, 2022 at 02:05:18PM -0800, Stefano Stabellini wrote: > On Mon, 14 Feb 2022, Oleksii Moisieiev wrote: > > Hi Bertrand, > > > > On Mon, Feb 14, 2022 at 11:27:21AM +, Bertrand Marquis wrote: > > > Hi Oleksii, > > > > > > > On 14 Feb 2022, at 11:13, Oleksii Moisieiev > > > > wrote: > > > > > > > > Hi Julien, > > > > > > > > On Sat, Feb 12, 2022 at 12:43:56PM +, Julien Grall wrote: > > > >> Hi, > > > >> > > > >> On 11/02/2022 11:18, Bertrand Marquis wrote: > > > >>> Do you plan to add support for other boards ? > > > >>> > > > >>> Did you discuss more in general with the linux kernel guys to see if > > > >>> this > > > >>> approach was agreed and will be adopted by other manufacturers ? > > > >>> > > > >>> All in all I think this is a good idea but I fear that all this will > > > >>> actually only > > > >>> be used by one board or one manufacturer and other might use a > > > >>> different > > > >>> strategy, I would like to unrisk this before merging this in Xen. > > > >> > > > >> In the past we merged code that would only benefits one vendor (i.e. > > > >> EEMI). > > > >> That said, this was a vendor specific protocol. I believe the > > > >> situation is > > > >> different here because the spec is meant to be generic. > > > >> > > > >>> @julien and Stefano: what is your view here ? > > > >> > > > >> I share the same concerns as you. I think we need to make sure all the > > > >> pieces we rely on (e.g. firmware, DT bindings) have been agreed before > > > >> we > > > >> can merge such code in Xen. > > > >> > > > >> The first step is to have all the pieces available in public so they > > > >> can be > > > >> reviewed and tested together. > > > >> > > > >> Oleksii, on a separate e-mail, you said you made change for ATF. How > > > >> much of > > > >> those changes was related to support for Xen? If they are some, then I > > > >> think > > > >> they should be upstreamed first. > > > >> > > > > > > > > Let me share changes, that were done to AT-F and Linux kernel > > > > device-tree in terms of the SCMI mediator POC. > > > > Changes to the Linux kernel: > > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0fTMUUSV$ > > > > [github[.]com] > > > > Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5 > > > > > > > > Changes to AT-F: > > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/linux-bsp/pull/3__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0eDKS3ge$ > > > > [github[.]com] > > > > Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5. > > > > > > You inverted the links but thanks this is really useful. > > > > > > > That's strange. Links looks good from xen.markmail.org interface. > > > > > Did you push the ATF changes to mainstream ATF or discuss those with > > > the maintainers ? > > > > No. We did changes in ATF as a proof of concept. > > > > > > > > The strategy overall is nice but we need to make sure this is accepted and > > > merged by all parties (ATF and Linux) to make sure the support for this > > > will > > > not only be available in Xen and for one board. > > +1 > > > > I've prepared patch to Linux kernel, which is introducing scmi_devid > > binding, needed to set device permissions via SCMI. I've contacted > > Sudeep Holla , who is the maintainer of the SCMI > > protocol > > drivers. Waiting for the response. > > > > Changes to ATF are not Xen specific and were done in terms of POC. We do > > not have plans to upstream those changes right now. > > If this work relies on a new interface in ATF, and the interface is not > vendor-specific, then at least the interface (if not the code) should be > reviewed and accepted by ATF. > > Otherwise we risk ending up with an upstream SCMI implementation in Xen > that cannot be used anywhere, except the PoC. To make things worse, this > could happen: > > - we upstream the SCMI mediator to Xen > - we upstream any required changes to Linux > - ATF rejects the SCMI-related interface changes > - ATF comes up with a difference interface > > At this point we would have to deprecate the implementation in Xen. It > might also be difficult to do so due to versioning issues. We would > need to be able to detect which version of ATF we are running on, to > distinguish the ATF PoC version that works with the old interface from > the new ATF version that supports a different interface. > > To avoid this kind of issues we typically expect that all relevant > communities agree on the public interfaces before upstreaming the code. That's sound reasonable. I'll contact with AT-F maintainers. Maybe I'll be able to upstream SCMI to AT-F. Also I hope I'll be able to contact Linux kernel SCMI maintainers and discuss device-tree structure. Best regards, Oleksii
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
On Mon, 14 Feb 2022, Oleksii Moisieiev wrote: > Hi Bertrand, > > On Mon, Feb 14, 2022 at 11:27:21AM +, Bertrand Marquis wrote: > > Hi Oleksii, > > > > > On 14 Feb 2022, at 11:13, Oleksii Moisieiev > > > wrote: > > > > > > Hi Julien, > > > > > > On Sat, Feb 12, 2022 at 12:43:56PM +, Julien Grall wrote: > > >> Hi, > > >> > > >> On 11/02/2022 11:18, Bertrand Marquis wrote: > > >>> Do you plan to add support for other boards ? > > >>> > > >>> Did you discuss more in general with the linux kernel guys to see if > > >>> this > > >>> approach was agreed and will be adopted by other manufacturers ? > > >>> > > >>> All in all I think this is a good idea but I fear that all this will > > >>> actually only > > >>> be used by one board or one manufacturer and other might use a different > > >>> strategy, I would like to unrisk this before merging this in Xen. > > >> > > >> In the past we merged code that would only benefits one vendor (i.e. > > >> EEMI). > > >> That said, this was a vendor specific protocol. I believe the situation > > >> is > > >> different here because the spec is meant to be generic. > > >> > > >>> @julien and Stefano: what is your view here ? > > >> > > >> I share the same concerns as you. I think we need to make sure all the > > >> pieces we rely on (e.g. firmware, DT bindings) have been agreed before we > > >> can merge such code in Xen. > > >> > > >> The first step is to have all the pieces available in public so they can > > >> be > > >> reviewed and tested together. > > >> > > >> Oleksii, on a separate e-mail, you said you made change for ATF. How > > >> much of > > >> those changes was related to support for Xen? If they are some, then I > > >> think > > >> they should be upstreamed first. > > >> > > > > > > Let me share changes, that were done to AT-F and Linux kernel > > > device-tree in terms of the SCMI mediator POC. > > > Changes to the Linux kernel: > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0fTMUUSV$ > > > [github[.]com] > > > Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5 > > > > > > Changes to AT-F: > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/linux-bsp/pull/3__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0eDKS3ge$ > > > [github[.]com] > > > Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5. > > > > You inverted the links but thanks this is really useful. > > > > That's strange. Links looks good from xen.markmail.org interface. > > > Did you push the ATF changes to mainstream ATF or discuss those with > > the maintainers ? > > No. We did changes in ATF as a proof of concept. > > > > > The strategy overall is nice but we need to make sure this is accepted and > > merged by all parties (ATF and Linux) to make sure the support for this > > will > > not only be available in Xen and for one board. +1 > I've prepared patch to Linux kernel, which is introducing scmi_devid > binding, needed to set device permissions via SCMI. I've contacted > Sudeep Holla , who is the maintainer of the SCMI > protocol > drivers. Waiting for the response. > > Changes to ATF are not Xen specific and were done in terms of POC. We do > not have plans to upstream those changes right now. If this work relies on a new interface in ATF, and the interface is not vendor-specific, then at least the interface (if not the code) should be reviewed and accepted by ATF. Otherwise we risk ending up with an upstream SCMI implementation in Xen that cannot be used anywhere, except the PoC. To make things worse, this could happen: - we upstream the SCMI mediator to Xen - we upstream any required changes to Linux - ATF rejects the SCMI-related interface changes - ATF comes up with a difference interface At this point we would have to deprecate the implementation in Xen. It might also be difficult to do so due to versioning issues. We would need to be able to detect which version of ATF we are running on, to distinguish the ATF PoC version that works with the old interface from the new ATF version that supports a different interface. To avoid this kind of issues we typically expect that all relevant communities agree on the public interfaces before upstreaming the code.
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi Bertrand, On Mon, Feb 14, 2022 at 11:27:21AM +, Bertrand Marquis wrote: > Hi Oleksii, > > > On 14 Feb 2022, at 11:13, Oleksii Moisieiev > > wrote: > > > > Hi Julien, > > > > On Sat, Feb 12, 2022 at 12:43:56PM +, Julien Grall wrote: > >> Hi, > >> > >> On 11/02/2022 11:18, Bertrand Marquis wrote: > >>> Do you plan to add support for other boards ? > >>> > >>> Did you discuss more in general with the linux kernel guys to see if this > >>> approach was agreed and will be adopted by other manufacturers ? > >>> > >>> All in all I think this is a good idea but I fear that all this will > >>> actually only > >>> be used by one board or one manufacturer and other might use a different > >>> strategy, I would like to unrisk this before merging this in Xen. > >> > >> In the past we merged code that would only benefits one vendor (i.e. EEMI). > >> That said, this was a vendor specific protocol. I believe the situation is > >> different here because the spec is meant to be generic. > >> > >>> @julien and Stefano: what is your view here ? > >> > >> I share the same concerns as you. I think we need to make sure all the > >> pieces we rely on (e.g. firmware, DT bindings) have been agreed before we > >> can merge such code in Xen. > >> > >> The first step is to have all the pieces available in public so they can be > >> reviewed and tested together. > >> > >> Oleksii, on a separate e-mail, you said you made change for ATF. How much > >> of > >> those changes was related to support for Xen? If they are some, then I > >> think > >> they should be upstreamed first. > >> > > > > Let me share changes, that were done to AT-F and Linux kernel > > device-tree in terms of the SCMI mediator POC. > > Changes to the Linux kernel: > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0fTMUUSV$ > > [github[.]com] > > Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5 > > > > Changes to AT-F: > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/linux-bsp/pull/3__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0eDKS3ge$ > > [github[.]com] > > Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5. > > You inverted the links but thanks this is really useful. > That's strange. Links looks good from xen.markmail.org interface. > Did you push the ATF changes to mainstream ATF or discuss those with > the maintainers ? No. We did changes in ATF as a proof of concept. > > The strategy overall is nice but we need to make sure this is accepted and > merged by all parties (ATF and Linux) to make sure the support for this will > not only be available in Xen and for one board. I've prepared patch to Linux kernel, which is introducing scmi_devid binding, needed to set device permissions via SCMI. I've contacted Sudeep Holla , who is the maintainer of the SCMI protocol drivers. Waiting for the response. Changes to ATF are not Xen specific and were done in terms of POC. We do not have plans to upstream those changes right now. > > I will try to get in touch with the SCMI linux driver maintainer at arm to > get his view. > Thanks. Best regards, Oleksii.
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi Oleksii, > On 14 Feb 2022, at 11:13, Oleksii Moisieiev > wrote: > > Hi Julien, > > On Sat, Feb 12, 2022 at 12:43:56PM +, Julien Grall wrote: >> Hi, >> >> On 11/02/2022 11:18, Bertrand Marquis wrote: >>> Do you plan to add support for other boards ? >>> >>> Did you discuss more in general with the linux kernel guys to see if this >>> approach was agreed and will be adopted by other manufacturers ? >>> >>> All in all I think this is a good idea but I fear that all this will >>> actually only >>> be used by one board or one manufacturer and other might use a different >>> strategy, I would like to unrisk this before merging this in Xen. >> >> In the past we merged code that would only benefits one vendor (i.e. EEMI). >> That said, this was a vendor specific protocol. I believe the situation is >> different here because the spec is meant to be generic. >> >>> @julien and Stefano: what is your view here ? >> >> I share the same concerns as you. I think we need to make sure all the >> pieces we rely on (e.g. firmware, DT bindings) have been agreed before we >> can merge such code in Xen. >> >> The first step is to have all the pieces available in public so they can be >> reviewed and tested together. >> >> Oleksii, on a separate e-mail, you said you made change for ATF. How much of >> those changes was related to support for Xen? If they are some, then I think >> they should be upstreamed first. >> > > Let me share changes, that were done to AT-F and Linux kernel > device-tree in terms of the SCMI mediator POC. > Changes to the Linux kernel: > https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4 > Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5 > > Changes to AT-F: > https://github.com/oleksiimoisieiev/linux-bsp/pull/3 > Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5. You inverted the links but thanks this is really useful. Did you push the ATF changes to mainstream ATF or discuss those with the maintainers ? The strategy overall is nice but we need to make sure this is accepted and merged by all parties (ATF and Linux) to make sure the support for this will not only be available in Xen and for one board. I will try to get in touch with the SCMI linux driver maintainer at arm to get his view. Regards Bertrand > > All changes that were done are not Xen specific. Given AT-F changes are > the implementation of the SCMI feature using SMC as transport. All > changes were done accoding to the DEN0056C [0] and DEN0028D [1]. > > We pass channel_id via SMC to the Firmware on r7 bits [15:0] (See Section > 4.1 of [1]). Then Firmware converts channel_id to agent_id. Channel_id can't > be > equal to agent_id in our case, because, according to the 4.2.2.8 of [0] > - agent_id 0 is reserved to identify platform itself. > > > [0] https://developer.arm.com/documentation/den0056/latest > [1] https://developer.arm.com/documentation/den0028/latest > > Best regards, > Oleksii.
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi Julien, On Sat, Feb 12, 2022 at 12:43:56PM +, Julien Grall wrote: > Hi, > > On 11/02/2022 11:18, Bertrand Marquis wrote: > > Do you plan to add support for other boards ? > > > > Did you discuss more in general with the linux kernel guys to see if this > > approach was agreed and will be adopted by other manufacturers ? > > > > All in all I think this is a good idea but I fear that all this will > > actually only > > be used by one board or one manufacturer and other might use a different > > strategy, I would like to unrisk this before merging this in Xen. > > In the past we merged code that would only benefits one vendor (i.e. EEMI). > That said, this was a vendor specific protocol. I believe the situation is > different here because the spec is meant to be generic. > > > @julien and Stefano: what is your view here ? > > I share the same concerns as you. I think we need to make sure all the > pieces we rely on (e.g. firmware, DT bindings) have been agreed before we > can merge such code in Xen. > > The first step is to have all the pieces available in public so they can be > reviewed and tested together. > > Oleksii, on a separate e-mail, you said you made change for ATF. How much of > those changes was related to support for Xen? If they are some, then I think > they should be upstreamed first. > Let me share changes, that were done to AT-F and Linux kernel device-tree in terms of the SCMI mediator POC. Changes to the Linux kernel: https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4 Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5 Changes to AT-F: https://github.com/oleksiimoisieiev/linux-bsp/pull/3 Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5. All changes that were done are not Xen specific. Given AT-F changes are the implementation of the SCMI feature using SMC as transport. All changes were done accoding to the DEN0056C [0] and DEN0028D [1]. We pass channel_id via SMC to the Firmware on r7 bits [15:0] (See Section 4.1 of [1]). Then Firmware converts channel_id to agent_id. Channel_id can't be equal to agent_id in our case, because, according to the 4.2.2.8 of [0] - agent_id 0 is reserved to identify platform itself. [0] https://developer.arm.com/documentation/den0056/latest [1] https://developer.arm.com/documentation/den0028/latest Best regards, Oleksii.
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi, On 11/02/2022 11:18, Bertrand Marquis wrote: Do you plan to add support for other boards ? Did you discuss more in general with the linux kernel guys to see if this approach was agreed and will be adopted by other manufacturers ? All in all I think this is a good idea but I fear that all this will actually only be used by one board or one manufacturer and other might use a different strategy, I would like to unrisk this before merging this in Xen. In the past we merged code that would only benefits one vendor (i.e. EEMI). That said, this was a vendor specific protocol. I believe the situation is different here because the spec is meant to be generic. @julien and Stefano: what is your view here ? I share the same concerns as you. I think we need to make sure all the pieces we rely on (e.g. firmware, DT bindings) have been agreed before we can merge such code in Xen. The first step is to have all the pieces available in public so they can be reviewed and tested together. Oleksii, on a separate e-mail, you said you made change for ATF. How much of those changes was related to support for Xen? If they are some, then I think they should be upstreamed first. Cheers, -- Julien Grall
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
On Fri, 11 Feb 2022, Oleksii Moisieiev wrote:
> On Fri, Feb 11, 2022 at 11:18:47AM +, Bertrand Marquis wrote:
> > Hi Oleksii,
> >
> >
> > > On 11 Feb 2022, at 10:44, Oleksii Moisieiev
> > > wrote:
> > >
> > > Hi Bertrand,
> > >
> > > On Fri, Feb 11, 2022 at 08:46:05AM +, Bertrand Marquis wrote:
> > >> Hi Oleksii,
> > >>
> > >>
> > >>> On 8 Feb 2022, at 18:00, Oleksii Moisieiev
> > >>> wrote:
> > >>>
> > >>> This is the implementation of SCI interface, called SCMI-SMC driver,
> > >>> which works as the mediator between XEN Domains and Firmware (SCP, ATF
> > >>> etc).
> > >>> This allows devices from the Domains to work with clocks, resets and
> > >>> power-domains without access to CPG.
> > >>>
> > >>> Originally, cpg should be passed to the domain so it can work with
> > >>> power-domains/clocks/resets etc. Considering that cpg can't be split
> > >>> between
> > >>> the Domains, we get the limitation that the devices, which are using
> > >>> power-domains/clocks/resets etc, couldn't be split between the domains.
> > >>> The solution is to move the power-domain/clock/resets etc to the
> > >>> Firmware (such as SCP firmware or ATF) and provide interface for the
> > >>> Domains. XEN should have an entity, caled SCI-Mediator, which is
> > >>> responsible for messages redirection between Domains and Firmware and
> > >>> for permission handling.
> > >>>
> > >>> The following features are implemented:
> > >>> - request SCMI channels from ATF and pass channels to Domains;
> > >>> - set device permissions for Domains based on the Domain partial
> > >>> device-tree. Devices with permissions are able to work with clocks,
> > >>> resets and power-domains via SCMI;
> > >>> - redirect scmi messages from Domains to ATF.
> > >>
> > >> Before going more deeply in the code I would like to discuss the general
> > >> design here and ask some questions to prevent to rework the code before
> > >> we all agree that this is the right solution and that we want this in
> > >> Xen.
> > >>
> > >> First I want to point out that clock/reset/power virtualization is a
> > >> problem
> > >> on most applications using device pass-through and I am very glad that
> > >> someone is looking into it.
> > >> Also SCMI is the current standard existing for this so relying on it is
> > >> a very
> > >> good idea.
> > >>
> > >> Latest version SCMI standard (DEN0056D v3.1) is defining some means
> > >> to use SCMI on a virtualised system. In chapter 4.2.1, the standard
> > >> recommends to set permissions per agent in the hypervisor so that a VM
> > >> could later use the discovery protocol to detect the resources and use
> > >> them.
> > >> Using this kind of scenario the mediator in Xen would just configure the
> > >> Permissions in the SCMI and would then rely on it to limit what is
> > >> possible
> > >> by who just by just assigning a channel to a VM.
> > >
> > >>
> > >> In your current design (please correct me if I am wrong) you seem to
> > >> fully
> > >> rely on Xen and the FDT for discovery and permission.
> > >
> > > In current implementation Xen is the trusted agent. And it's responsible
> > > for permissions setting. During initialization it discovers agent and
> > > set permissions by using BASE_SET_DEVICE_PERMISSIONS to the Dom0. When
> > > new domain is created, Xen assigns agent id for this domain and request
> > > resources, that are passed-through to this Domain.
> >
> > Ok
> >
> > >
> > > I'm getting the follwing information from FDT:
> > > 1) Shared memory addressed, which should be used for agents. During
> > > initialization I send BASE_DISCOVER_AGENT to each of this addresses and
> > > receive agent_id. Xen is responsible for assigning agent_id for the
> > > Domain. Then Xen intercept smc calls from the domain, set agent_id and
> > > redirects it to the Firmware.
> >
> > So Xen is setting the agent ID, no way for a guest to get access to
> > something it
> > should with more check, am I right ?
> >
>
> Yes. Xen is the only entity, which is trusted. So it's responsible for
> setting permissions and assigning agent_id. Guest get's an access only
> for the devices it's allowed to.
>
> > >
> > > 2) Devices, that are using SCMI. Those devices has clock/power/resets
> > > etc related to scmi protocol (as it is done in Linux kernel)
> > > and scmi_devid should be set. I'm currently preparing to send patch,
> > > updating kernel bindings with this parameter to Linux kernel.
> > > scmi_devid value should match device id, set in the Firmware.
> > > dt example:
> > > {
> > >scmi_devid = <1>; // usb0 device id
> > >clocks = <_clock 1> // relays on clock with id 1
> > > }
> > >
> > > Xen requests permission for the device when device is attached to the
> > > Domain during creation.
> >
> > Without this, how is (if it is) the linux kernel using SCMI for power
> > management ?
>
> Here is how it should be desribed in FDT:
> /
> {
> firmware {
> scmi {
>
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
On Fri, Feb 11, 2022 at 11:18:47AM +, Bertrand Marquis wrote:
> Hi Oleksii,
>
>
> > On 11 Feb 2022, at 10:44, Oleksii Moisieiev
> > wrote:
> >
> > Hi Bertrand,
> >
> > On Fri, Feb 11, 2022 at 08:46:05AM +, Bertrand Marquis wrote:
> >> Hi Oleksii,
> >>
> >>
> >>> On 8 Feb 2022, at 18:00, Oleksii Moisieiev
> >>> wrote:
> >>>
> >>> This is the implementation of SCI interface, called SCMI-SMC driver,
> >>> which works as the mediator between XEN Domains and Firmware (SCP, ATF
> >>> etc).
> >>> This allows devices from the Domains to work with clocks, resets and
> >>> power-domains without access to CPG.
> >>>
> >>> Originally, cpg should be passed to the domain so it can work with
> >>> power-domains/clocks/resets etc. Considering that cpg can't be split
> >>> between
> >>> the Domains, we get the limitation that the devices, which are using
> >>> power-domains/clocks/resets etc, couldn't be split between the domains.
> >>> The solution is to move the power-domain/clock/resets etc to the
> >>> Firmware (such as SCP firmware or ATF) and provide interface for the
> >>> Domains. XEN should have an entity, caled SCI-Mediator, which is
> >>> responsible for messages redirection between Domains and Firmware and
> >>> for permission handling.
> >>>
> >>> The following features are implemented:
> >>> - request SCMI channels from ATF and pass channels to Domains;
> >>> - set device permissions for Domains based on the Domain partial
> >>> device-tree. Devices with permissions are able to work with clocks,
> >>> resets and power-domains via SCMI;
> >>> - redirect scmi messages from Domains to ATF.
> >>
> >> Before going more deeply in the code I would like to discuss the general
> >> design here and ask some questions to prevent to rework the code before
> >> we all agree that this is the right solution and that we want this in Xen.
> >>
> >> First I want to point out that clock/reset/power virtualization is a
> >> problem
> >> on most applications using device pass-through and I am very glad that
> >> someone is looking into it.
> >> Also SCMI is the current standard existing for this so relying on it is a
> >> very
> >> good idea.
> >>
> >> Latest version SCMI standard (DEN0056D v3.1) is defining some means
> >> to use SCMI on a virtualised system. In chapter 4.2.1, the standard
> >> recommends to set permissions per agent in the hypervisor so that a VM
> >> could later use the discovery protocol to detect the resources and use
> >> them.
> >> Using this kind of scenario the mediator in Xen would just configure the
> >> Permissions in the SCMI and would then rely on it to limit what is possible
> >> by who just by just assigning a channel to a VM.
> >
> >>
> >> In your current design (please correct me if I am wrong) you seem to fully
> >> rely on Xen and the FDT for discovery and permission.
> >
> > In current implementation Xen is the trusted agent. And it's responsible
> > for permissions setting. During initialization it discovers agent and
> > set permissions by using BASE_SET_DEVICE_PERMISSIONS to the Dom0. When
> > new domain is created, Xen assigns agent id for this domain and request
> > resources, that are passed-through to this Domain.
>
> Ok
>
> >
> > I'm getting the follwing information from FDT:
> > 1) Shared memory addressed, which should be used for agents. During
> > initialization I send BASE_DISCOVER_AGENT to each of this addresses and
> > receive agent_id. Xen is responsible for assigning agent_id for the
> > Domain. Then Xen intercept smc calls from the domain, set agent_id and
> > redirects it to the Firmware.
>
> So Xen is setting the agent ID, no way for a guest to get access to something
> it
> should with more check, am I right ?
>
Yes. Xen is the only entity, which is trusted. So it's responsible for
setting permissions and assigning agent_id. Guest get's an access only
for the devices it's allowed to.
> >
> > 2) Devices, that are using SCMI. Those devices has clock/power/resets
> > etc related to scmi protocol (as it is done in Linux kernel)
> > and scmi_devid should be set. I'm currently preparing to send patch,
> > updating kernel bindings with this parameter to Linux kernel.
> > scmi_devid value should match device id, set in the Firmware.
> > dt example:
> > {
> >scmi_devid = <1>; // usb0 device id
> >clocks = <_clock 1> // relays on clock with id 1
> > }
> >
> > Xen requests permission for the device when device is attached to the
> > Domain during creation.
>
> Without this, how is (if it is) the linux kernel using SCMI for power
> management ?
Here is how it should be desribed in FDT:
/
{
firmware {
scmi {
arm,smc-id = <0x8202>;
scmi_power: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
...
scmi_clock: protocol@14 {
...
scmi_reset: protocol@16 {
...
};
};
};
{
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi Oleksii,
> On 11 Feb 2022, at 10:44, Oleksii Moisieiev
> wrote:
>
> Hi Bertrand,
>
> On Fri, Feb 11, 2022 at 08:46:05AM +, Bertrand Marquis wrote:
>> Hi Oleksii,
>>
>>
>>> On 8 Feb 2022, at 18:00, Oleksii Moisieiev
>>> wrote:
>>>
>>> This is the implementation of SCI interface, called SCMI-SMC driver,
>>> which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
>>> This allows devices from the Domains to work with clocks, resets and
>>> power-domains without access to CPG.
>>>
>>> Originally, cpg should be passed to the domain so it can work with
>>> power-domains/clocks/resets etc. Considering that cpg can't be split between
>>> the Domains, we get the limitation that the devices, which are using
>>> power-domains/clocks/resets etc, couldn't be split between the domains.
>>> The solution is to move the power-domain/clock/resets etc to the
>>> Firmware (such as SCP firmware or ATF) and provide interface for the
>>> Domains. XEN should have an entity, caled SCI-Mediator, which is
>>> responsible for messages redirection between Domains and Firmware and
>>> for permission handling.
>>>
>>> The following features are implemented:
>>> - request SCMI channels from ATF and pass channels to Domains;
>>> - set device permissions for Domains based on the Domain partial
>>> device-tree. Devices with permissions are able to work with clocks,
>>> resets and power-domains via SCMI;
>>> - redirect scmi messages from Domains to ATF.
>>
>> Before going more deeply in the code I would like to discuss the general
>> design here and ask some questions to prevent to rework the code before
>> we all agree that this is the right solution and that we want this in Xen.
>>
>> First I want to point out that clock/reset/power virtualization is a problem
>> on most applications using device pass-through and I am very glad that
>> someone is looking into it.
>> Also SCMI is the current standard existing for this so relying on it is a
>> very
>> good idea.
>>
>> Latest version SCMI standard (DEN0056D v3.1) is defining some means
>> to use SCMI on a virtualised system. In chapter 4.2.1, the standard
>> recommends to set permissions per agent in the hypervisor so that a VM
>> could later use the discovery protocol to detect the resources and use them.
>> Using this kind of scenario the mediator in Xen would just configure the
>> Permissions in the SCMI and would then rely on it to limit what is possible
>> by who just by just assigning a channel to a VM.
>
>>
>> In your current design (please correct me if I am wrong) you seem to fully
>> rely on Xen and the FDT for discovery and permission.
>
> In current implementation Xen is the trusted agent. And it's responsible
> for permissions setting. During initialization it discovers agent and
> set permissions by using BASE_SET_DEVICE_PERMISSIONS to the Dom0. When
> new domain is created, Xen assigns agent id for this domain and request
> resources, that are passed-through to this Domain.
Ok
>
> I'm getting the follwing information from FDT:
> 1) Shared memory addressed, which should be used for agents. During
> initialization I send BASE_DISCOVER_AGENT to each of this addresses and
> receive agent_id. Xen is responsible for assigning agent_id for the
> Domain. Then Xen intercept smc calls from the domain, set agent_id and
> redirects it to the Firmware.
So Xen is setting the agent ID, no way for a guest to get access to something it
should with more check, am I right ?
>
> 2) Devices, that are using SCMI. Those devices has clock/power/resets
> etc related to scmi protocol (as it is done in Linux kernel)
> and scmi_devid should be set. I'm currently preparing to send patch,
> updating kernel bindings with this parameter to Linux kernel.
> scmi_devid value should match device id, set in the Firmware.
> dt example:
> {
>scmi_devid = <1>; // usb0 device id
>clocks = <_clock 1> // relays on clock with id 1
> }
>
> Xen requests permission for the device when device is attached to the
> Domain during creation.
Without this, how is (if it is) the linux kernel using SCMI for power
management ?
>
>> Wouldn’t it be a better idea to use the protocol fully ?
>
> Hm, I was thinking I am using the protocol fully. Did I miss something?
Sorry you seem to be, my understanding of your design was not right.
>
>> Could we get rid of some of the FDT dependencies by using the discovery
>> system of SCMI ?
>
> I'm using FDT to get shmem regions for the channels. Then I send
> BASE_DISCOVER_AGENT to each region and getting agent data. Did I use the
> discovery system wrong?
After more digging it seems you are. The link between scmi resource and device
is not possible to get automatically.
>
>> How is Linux doing this currently ? Is it relying on device tree to discover
>> the SCMI resources ?
>
> Yes. Linux kernel has 2 nodes in the device-tree: arm,scmi-shmem, which
> includes memory region for the communication and arm,scmi-smc node,
>
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi Bertrand,
On Fri, Feb 11, 2022 at 08:46:05AM +, Bertrand Marquis wrote:
> Hi Oleksii,
>
>
> > On 8 Feb 2022, at 18:00, Oleksii Moisieiev
> > wrote:
> >
> > This is the implementation of SCI interface, called SCMI-SMC driver,
> > which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
> > This allows devices from the Domains to work with clocks, resets and
> > power-domains without access to CPG.
> >
> > Originally, cpg should be passed to the domain so it can work with
> > power-domains/clocks/resets etc. Considering that cpg can't be split between
> > the Domains, we get the limitation that the devices, which are using
> > power-domains/clocks/resets etc, couldn't be split between the domains.
> > The solution is to move the power-domain/clock/resets etc to the
> > Firmware (such as SCP firmware or ATF) and provide interface for the
> > Domains. XEN should have an entity, caled SCI-Mediator, which is
> > responsible for messages redirection between Domains and Firmware and
> > for permission handling.
> >
> > The following features are implemented:
> > - request SCMI channels from ATF and pass channels to Domains;
> > - set device permissions for Domains based on the Domain partial
> > device-tree. Devices with permissions are able to work with clocks,
> > resets and power-domains via SCMI;
> > - redirect scmi messages from Domains to ATF.
>
> Before going more deeply in the code I would like to discuss the general
> design here and ask some questions to prevent to rework the code before
> we all agree that this is the right solution and that we want this in Xen.
>
> First I want to point out that clock/reset/power virtualization is a problem
> on most applications using device pass-through and I am very glad that
> someone is looking into it.
> Also SCMI is the current standard existing for this so relying on it is a very
> good idea.
>
> Latest version SCMI standard (DEN0056D v3.1) is defining some means
> to use SCMI on a virtualised system. In chapter 4.2.1, the standard
> recommends to set permissions per agent in the hypervisor so that a VM
> could later use the discovery protocol to detect the resources and use them.
> Using this kind of scenario the mediator in Xen would just configure the
> Permissions in the SCMI and would then rely on it to limit what is possible
> by who just by just assigning a channel to a VM.
>
> In your current design (please correct me if I am wrong) you seem to fully
> rely on Xen and the FDT for discovery and permission.
In current implementation Xen is the trusted agent. And it's responsible
for permissions setting. During initialization it discovers agent and
set permissions by using BASE_SET_DEVICE_PERMISSIONS to the Dom0. When
new domain is created, Xen assigns agent id for this domain and request
resources, that are passed-through to this Domain.
I'm getting the follwing information from FDT:
1) Shared memory addressed, which should be used for agents. During
initialization I send BASE_DISCOVER_AGENT to each of this addresses and
receive agent_id. Xen is responsible for assigning agent_id for the
Domain. Then Xen intercept smc calls from the domain, set agent_id and
redirects it to the Firmware.
2) Devices, that are using SCMI. Those devices has clock/power/resets
etc related to scmi protocol (as it is done in Linux kernel)
and scmi_devid should be set. I'm currently preparing to send patch,
updating kernel bindings with this parameter to Linux kernel.
scmi_devid value should match device id, set in the Firmware.
dt example:
{
scmi_devid = <1>; // usb0 device id
clocks = <_clock 1> // relays on clock with id 1
}
Xen requests permission for the device when device is attached to the
Domain during creation.
> Wouldn’t it be a better idea to use the protocol fully ?
Hm, I was thinking I am using the protocol fully. Did I miss something?
> Could we get rid of some of the FDT dependencies by using the discovery
> system of SCMI ?
I'm using FDT to get shmem regions for the channels. Then I send
BASE_DISCOVER_AGENT to each region and getting agent data. Did I use the
discovery system wrong?
> How is Linux doing this currently ? Is it relying on device tree to discover
> the SCMI resources ?
Yes. Linux kernel has 2 nodes in the device-tree: arm,scmi-shmem, which
includes memory region for the communication and arm,scmi-smc node,
which describes all data related to scmi ( func_id, protocols etc)
Then the device nodes refer to the protocols by setting
clock/resets/power-domains etc. Please see the example above.
BASE_DISCOVER_AGENT is not used in Linux kernel.
The main idea was that scmi related changes to the device-tree are
common for virtualized and non virtualized systems. So the same FDT
configuration should work with of without Xen.
>
> Also I understand that you rely on some entries to be declared in the device
> tree and also some support to be implemented in ATF or SCP. I checked in
> The boards I have
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi Oleksii, > On 8 Feb 2022, at 18:00, Oleksii Moisieiev wrote: > > This is the implementation of SCI interface, called SCMI-SMC driver, > which works as the mediator between XEN Domains and Firmware (SCP, ATF etc). > This allows devices from the Domains to work with clocks, resets and > power-domains without access to CPG. > > Originally, cpg should be passed to the domain so it can work with > power-domains/clocks/resets etc. Considering that cpg can't be split between > the Domains, we get the limitation that the devices, which are using > power-domains/clocks/resets etc, couldn't be split between the domains. > The solution is to move the power-domain/clock/resets etc to the > Firmware (such as SCP firmware or ATF) and provide interface for the > Domains. XEN should have an entity, caled SCI-Mediator, which is > responsible for messages redirection between Domains and Firmware and > for permission handling. > > The following features are implemented: > - request SCMI channels from ATF and pass channels to Domains; > - set device permissions for Domains based on the Domain partial > device-tree. Devices with permissions are able to work with clocks, > resets and power-domains via SCMI; > - redirect scmi messages from Domains to ATF. Before going more deeply in the code I would like to discuss the general design here and ask some questions to prevent to rework the code before we all agree that this is the right solution and that we want this in Xen. First I want to point out that clock/reset/power virtualization is a problem on most applications using device pass-through and I am very glad that someone is looking into it. Also SCMI is the current standard existing for this so relying on it is a very good idea. Latest version SCMI standard (DEN0056D v3.1) is defining some means to use SCMI on a virtualised system. In chapter 4.2.1, the standard recommends to set permissions per agent in the hypervisor so that a VM could later use the discovery protocol to detect the resources and use them. Using this kind of scenario the mediator in Xen would just configure the Permissions in the SCMI and would then rely on it to limit what is possible by who just by just assigning a channel to a VM. In your current design (please correct me if I am wrong) you seem to fully rely on Xen and the FDT for discovery and permission. Wouldn’t it be a better idea to use the protocol fully ? Could we get rid of some of the FDT dependencies by using the discovery system of SCMI ? How is Linux doing this currently ? Is it relying on device tree to discover the SCMI resources ? Also I understand that you rely on some entries to be declared in the device tree and also some support to be implemented in ATF or SCP. I checked in The boards I have access to and the device trees but none of this seem to be supported there. Could you tell which board/configuration/ATF you are using so that the implementation could be tested/validated ? Regards Bertrand > > Signed-off-by: Oleksii Moisieiev > --- > xen/arch/arm/Kconfig| 2 + > xen/arch/arm/sci/Kconfig| 10 + > xen/arch/arm/sci/scmi_smc.c | 959 > 3 files changed, 971 insertions(+) > create mode 100644 xen/arch/arm/sci/Kconfig > create mode 100644 xen/arch/arm/sci/scmi_smc.c > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index ab07833582..3b0dfc57b6 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -123,6 +123,8 @@ config ARM_SCI > support. It allows guests to control system resourcess via one of > ARM_SCI mediators implemented in XEN. > > + source "arch/arm/sci/Kconfig" > + > endmenu > > menu "ARM errata workaround via the alternative framework" > diff --git a/xen/arch/arm/sci/Kconfig b/xen/arch/arm/sci/Kconfig > new file mode 100644 > index 00..10b634d2ed > --- /dev/null > +++ b/xen/arch/arm/sci/Kconfig > @@ -0,0 +1,10 @@ > +config SCMI_SMC > + bool "Enable SCMI-SMC mediator driver" > + default n > + depends on ARM_SCI && HOST_DTB_EXPORT > + ---help--- > + > + Enables mediator in XEN to pass SCMI requests from Domains to ATF. > + This feature allows drivers from Domains to work with System > + Controllers (such as power,resets,clock etc.). SCP is used as transport > + for communication. > diff --git a/xen/arch/arm/sci/scmi_smc.c b/xen/arch/arm/sci/scmi_smc.c > new file mode 100644 > index 00..103529dfab > --- /dev/null > +++ b/xen/arch/arm/sci/scmi_smc.c > @@ -0,0 +1,959 @@ > +/* > + * xen/arch/arm/sci/scmi_smc.c > + * > + * SCMI mediator driver, using SCP as transport. > + * > + * Oleksii Moisieiev > + * Copyright (C) 2021, EPAM Systems. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + *
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
On 09/02/2022 15:02, Oleksandr Andrushchenko wrote:
+{
+return FIELD_PREP(HDR_ID, hdr->id) |
+FIELD_PREP(HDR_TYPE, hdr->type) |
+FIELD_PREP(HDR_PROTO, hdr->protocol);
+}
+
+/*
+ * unpack_scmi_header() - unpacks and records message and protocol id
+ *
+ * @msg_hdr: 32-bit packed message header sent from the platform
+ * @hdr: pointer to header to fetch message and protocol id.
+ */
+static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t *hdr)
+{
+hdr->id = FIELD_GET(HDR_ID, msg_hdr);
+hdr->type = FIELD_GET(HDR_TYPE, msg_hdr);
+hdr->protocol = FIELD_GET(HDR_PROTO, msg_hdr);
+}
+
+static inline int channel_is_free(struct scmi_channel *chan_info)
+{
+return ( chan_info->shmem->channel_status
+& SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE ) ? 0 : -EBUSY;
+}
+
+/*
+ * Copy data from IO memory space to "real" memory space.
+ */
+void __memcpy_fromio(void *to, const volatile void __iomem *from, size_t count)
This seems to be a copy of [2].
We should think about moving this into a dedicated file like in Linux,
preserving the authorship+
+1. Also this should be in a separate patch.
Cheers,
--
Julien Grall
Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Hi, Oleksii!
On 08.02.22 20:00, Oleksii Moisieiev wrote:
> This is the implementation of SCI interface, called SCMI-SMC driver,
> which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
> This allows devices from the Domains to work with clocks, resets and
> power-domains without access to CPG.
>
> Originally, cpg should be passed to the domain so it can work with
> power-domains/clocks/resets etc. Considering that cpg can't be split between
> the Domains, we get the limitation that the devices, which are using
> power-domains/clocks/resets etc, couldn't be split between the domains.
> The solution is to move the power-domain/clock/resets etc to the
> Firmware (such as SCP firmware or ATF) and provide interface for the
> Domains. XEN should have an entity, caled SCI-Mediator, which is
> responsible for messages redirection between Domains and Firmware and
> for permission handling.
>
> The following features are implemented:
> - request SCMI channels from ATF and pass channels to Domains;
> - set device permissions for Domains based on the Domain partial
> device-tree. Devices with permissions are able to work with clocks,
> resets and power-domains via SCMI;
> - redirect scmi messages from Domains to ATF.
>
> Signed-off-by: Oleksii Moisieiev
> ---
> xen/arch/arm/Kconfig| 2 +
> xen/arch/arm/sci/Kconfig| 10 +
> xen/arch/arm/sci/scmi_smc.c | 959
> 3 files changed, 971 insertions(+)
> create mode 100644 xen/arch/arm/sci/Kconfig
> create mode 100644 xen/arch/arm/sci/scmi_smc.c
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index ab07833582..3b0dfc57b6 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -123,6 +123,8 @@ config ARM_SCI
> support. It allows guests to control system resourcess via one of
> ARM_SCI mediators implemented in XEN.
>
> + source "arch/arm/sci/Kconfig"
> +
> endmenu
>
> menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/sci/Kconfig b/xen/arch/arm/sci/Kconfig
> new file mode 100644
> index 00..10b634d2ed
> --- /dev/null
> +++ b/xen/arch/arm/sci/Kconfig
> @@ -0,0 +1,10 @@
> +config SCMI_SMC
> + bool "Enable SCMI-SMC mediator driver"
> + default n
> + depends on ARM_SCI && HOST_DTB_EXPORT
> + ---help---
> +
> + Enables mediator in XEN to pass SCMI requests from Domains to ATF.
> + This feature allows drivers from Domains to work with System
> + Controllers (such as power,resets,clock etc.). SCP is used as transport
> + for communication.
> diff --git a/xen/arch/arm/sci/scmi_smc.c b/xen/arch/arm/sci/scmi_smc.c
> new file mode 100644
> index 00..103529dfab
> --- /dev/null
> +++ b/xen/arch/arm/sci/scmi_smc.c
> @@ -0,0 +1,959 @@
> +/*
> + * xen/arch/arm/sci/scmi_smc.c
> + *
> + * SCMI mediator driver, using SCP as transport.
> + *
> + * Oleksii Moisieiev
> + * Copyright (C) 2021, EPAM Systems.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SCMI_BASE_PROTOCOL 0x10
> +#define SCMI_BASE_PROTOCOL_ATTIBUTES0x1
> +#define SCMI_BASE_SET_DEVICE_PERMISSIONS0x9
> +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB
> +#define SCMI_BASE_DISCOVER_AGENT0x7
Can the above be sorted?
> +
> +/* SCMI return codes. See section 4.1.4 of SCMI spec (DEN0056C) */
> +#define SCMI_SUCCESS 0
> +#define SCMI_NOT_SUPPORTED (-1)
> +#define SCMI_INVALID_PARAMETERS (-2)
> +#define SCMI_DENIED (-3)
> +#define SCMI_NOT_FOUND (-4)
> +#define SCMI_OUT_OF_RANGE (-5)
> +#define SCMI_BUSY (-6)
> +#define SCMI_COMMS_ERROR(-7)
> +#define SCMI_GENERIC_ERROR (-8)
> +#define SCMI_HARDWARE_ERROR (-9)
> +#define SCMI_PROTOCOL_ERROR (-10)
> +
> +#define DT_MATCH_SCMI_SMC DT_MATCH_COMPATIBLE("arm,scmi-smc")
> +
> +#define SCMI_SMC_ID"arm,smc-id"
> +#define SCMI_SHARED_MEMORY "arm,scmi-shmem"
> +#define SCMI_SHMEM "shmem"
> +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE
> +
> +#define HYP_CHANNEL 0x0
Alignment
> +
> +#define HDR_ID GENMASK(7,0)
> +#define HDR_TYPE
[RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
This is the implementation of SCI interface, called SCMI-SMC driver,
which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
This allows devices from the Domains to work with clocks, resets and
power-domains without access to CPG.
Originally, cpg should be passed to the domain so it can work with
power-domains/clocks/resets etc. Considering that cpg can't be split between
the Domains, we get the limitation that the devices, which are using
power-domains/clocks/resets etc, couldn't be split between the domains.
The solution is to move the power-domain/clock/resets etc to the
Firmware (such as SCP firmware or ATF) and provide interface for the
Domains. XEN should have an entity, caled SCI-Mediator, which is
responsible for messages redirection between Domains and Firmware and
for permission handling.
The following features are implemented:
- request SCMI channels from ATF and pass channels to Domains;
- set device permissions for Domains based on the Domain partial
device-tree. Devices with permissions are able to work with clocks,
resets and power-domains via SCMI;
- redirect scmi messages from Domains to ATF.
Signed-off-by: Oleksii Moisieiev
---
xen/arch/arm/Kconfig| 2 +
xen/arch/arm/sci/Kconfig| 10 +
xen/arch/arm/sci/scmi_smc.c | 959
3 files changed, 971 insertions(+)
create mode 100644 xen/arch/arm/sci/Kconfig
create mode 100644 xen/arch/arm/sci/scmi_smc.c
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index ab07833582..3b0dfc57b6 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -123,6 +123,8 @@ config ARM_SCI
support. It allows guests to control system resourcess via one of
ARM_SCI mediators implemented in XEN.
+ source "arch/arm/sci/Kconfig"
+
endmenu
menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/sci/Kconfig b/xen/arch/arm/sci/Kconfig
new file mode 100644
index 00..10b634d2ed
--- /dev/null
+++ b/xen/arch/arm/sci/Kconfig
@@ -0,0 +1,10 @@
+config SCMI_SMC
+ bool "Enable SCMI-SMC mediator driver"
+ default n
+ depends on ARM_SCI && HOST_DTB_EXPORT
+ ---help---
+
+ Enables mediator in XEN to pass SCMI requests from Domains to ATF.
+ This feature allows drivers from Domains to work with System
+ Controllers (such as power,resets,clock etc.). SCP is used as transport
+ for communication.
diff --git a/xen/arch/arm/sci/scmi_smc.c b/xen/arch/arm/sci/scmi_smc.c
new file mode 100644
index 00..103529dfab
--- /dev/null
+++ b/xen/arch/arm/sci/scmi_smc.c
@@ -0,0 +1,959 @@
+/*
+ * xen/arch/arm/sci/scmi_smc.c
+ *
+ * SCMI mediator driver, using SCP as transport.
+ *
+ * Oleksii Moisieiev
+ * Copyright (C) 2021, EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SCMI_BASE_PROTOCOL 0x10
+#define SCMI_BASE_PROTOCOL_ATTIBUTES0x1
+#define SCMI_BASE_SET_DEVICE_PERMISSIONS0x9
+#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB
+#define SCMI_BASE_DISCOVER_AGENT0x7
+
+/* SCMI return codes. See section 4.1.4 of SCMI spec (DEN0056C) */
+#define SCMI_SUCCESS 0
+#define SCMI_NOT_SUPPORTED (-1)
+#define SCMI_INVALID_PARAMETERS (-2)
+#define SCMI_DENIED (-3)
+#define SCMI_NOT_FOUND (-4)
+#define SCMI_OUT_OF_RANGE (-5)
+#define SCMI_BUSY (-6)
+#define SCMI_COMMS_ERROR(-7)
+#define SCMI_GENERIC_ERROR (-8)
+#define SCMI_HARDWARE_ERROR (-9)
+#define SCMI_PROTOCOL_ERROR (-10)
+
+#define DT_MATCH_SCMI_SMC DT_MATCH_COMPATIBLE("arm,scmi-smc")
+
+#define SCMI_SMC_ID"arm,smc-id"
+#define SCMI_SHARED_MEMORY "arm,scmi-shmem"
+#define SCMI_SHMEM "shmem"
+#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE
+
+#define HYP_CHANNEL 0x0
+
+#define HDR_ID GENMASK(7,0)
+#define HDR_TYPE GENMASK(9, 8)
+#define HDR_PROTO GENMASK(17, 10)
+
+/* SCMI protocol, refer to section 4.2.2.2 (DEN0056C) */
+#define MSG_N_AGENTS_MASK GENMASK(15, 8)
+
+#define FIELD_GET(_mask, _reg)\
+((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1)))
+#define
