| Message ID | 20240610065343.2594943-1-jens.wiklander@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | FF-A notifications | expand |
Hi Jens, > On 10 Jun 2024, at 08:53, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > Hi, > > This patch set adds support for FF-A notifications. We only support > global notifications, per vCPU notifications remain unsupported. > > The first three patches are further cleanup and can be merged before the > rest if desired. > > A physical SGI is used to make Xen aware of pending FF-A notifications. The > physical SGI is selected by the SPMC in the secure world. Since it must not > already be used by Xen the SPMC is in practice forced to donate one of the > secure SGIs, but that's normally not a problem. The SGI handling in Xen is > updated to support registration of handlers for SGIs that aren't statically > assigned, that is, SGI IDs above GIC_SGI_MAX. > > The patch "xen/arm: add and call init_tee_secondary()" provides a hook for > register the needed per-cpu interrupt handler in "xen/arm: ffa: support > notification". > > The patch "xen/arm: add and call tee_free_domain_ctx()" provides a hook for > later freeing of the TEE context. This hook is used in "xen/arm: ffa: > support notification" and avoids the problem with TEE context being freed > while we need to access it when handling a Schedule Receiver interrupt. It > was suggested as an alternative in [1] that the TEE context could be freed > from complete_domain_destroy(). > > [1] https://lore.kernel.org/all/CAHUa44H4YpoxYT7e6WNH5XJFpitZQjqP9Ng4SmTy4eWhyN+F+w@mail.gmail.com/ > > Thanks, > Jens All patches are now reviewed and/or acked so I think they can get in for the release. Regards Bertrand
Hi Bertrand, On 10/06/2024 16:54, Bertrand Marquis wrote: > Hi Jens, > >> On 10 Jun 2024, at 08:53, Jens Wiklander <jens.wiklander@linaro.org> wrote: >> >> Hi, >> >> This patch set adds support for FF-A notifications. We only support >> global notifications, per vCPU notifications remain unsupported. >> >> The first three patches are further cleanup and can be merged before the >> rest if desired. >> >> A physical SGI is used to make Xen aware of pending FF-A notifications. The >> physical SGI is selected by the SPMC in the secure world. Since it must not >> already be used by Xen the SPMC is in practice forced to donate one of the >> secure SGIs, but that's normally not a problem. The SGI handling in Xen is >> updated to support registration of handlers for SGIs that aren't statically >> assigned, that is, SGI IDs above GIC_SGI_MAX. >> >> The patch "xen/arm: add and call init_tee_secondary()" provides a hook for >> register the needed per-cpu interrupt handler in "xen/arm: ffa: support >> notification". >> >> The patch "xen/arm: add and call tee_free_domain_ctx()" provides a hook for >> later freeing of the TEE context. This hook is used in "xen/arm: ffa: >> support notification" and avoids the problem with TEE context being freed >> while we need to access it when handling a Schedule Receiver interrupt. It >> was suggested as an alternative in [1] that the TEE context could be freed >> from complete_domain_destroy(). >> >> [1] https://lore.kernel.org/all/CAHUa44H4YpoxYT7e6WNH5XJFpitZQjqP9Ng4SmTy4eWhyN+F+w@mail.gmail.com/ >> >> Thanks, >> Jens > > All patches are now reviewed and/or acked so I think they can get in for the release. This would need a release-ack from Oleksii (I can't seem to find already one). As we discussed last week, I am fine with the idea to merge the FFA patches as the feature is tech-preview. But there are some changes in the arm generic code. Do you (or Jens) have an assessment of the risk of the changes? Cheers,
Hi Julien and Oleksii, @Oleksii: Could we consider having this serie merged for next release ? It is a feature that is in tech-preview at the moment and as such should not have any consequences on existing system unless it is activated explicitly in the Xen configuration. There are some changes in the arm common code introducing support to register SGI interrupt handlers in drivers. As no drivers appart from FF-A is trying to register such handlers, the risk is minimal for existing systems. > On 10 Jun 2024, at 22:38, Julien Grall <julien@xen.org> wrote: > > Hi Bertrand, > > On 10/06/2024 16:54, Bertrand Marquis wrote: >> Hi Jens, >>> On 10 Jun 2024, at 08:53, Jens Wiklander <jens.wiklander@linaro.org> wrote: >>> >>> Hi, >>> >>> This patch set adds support for FF-A notifications. We only support >>> global notifications, per vCPU notifications remain unsupported. >>> >>> The first three patches are further cleanup and can be merged before the >>> rest if desired. >>> >>> A physical SGI is used to make Xen aware of pending FF-A notifications. The >>> physical SGI is selected by the SPMC in the secure world. Since it must not >>> already be used by Xen the SPMC is in practice forced to donate one of the >>> secure SGIs, but that's normally not a problem. The SGI handling in Xen is >>> updated to support registration of handlers for SGIs that aren't statically >>> assigned, that is, SGI IDs above GIC_SGI_MAX. >>> >>> The patch "xen/arm: add and call init_tee_secondary()" provides a hook for >>> register the needed per-cpu interrupt handler in "xen/arm: ffa: support >>> notification". >>> >>> The patch "xen/arm: add and call tee_free_domain_ctx()" provides a hook for >>> later freeing of the TEE context. This hook is used in "xen/arm: ffa: >>> support notification" and avoids the problem with TEE context being freed >>> while we need to access it when handling a Schedule Receiver interrupt. It >>> was suggested as an alternative in [1] that the TEE context could be freed >>> from complete_domain_destroy(). >>> >>> [1] https://lore.kernel.org/all/CAHUa44H4YpoxYT7e6WNH5XJFpitZQjqP9Ng4SmTy4eWhyN+F+w@mail.gmail.com/ >>> >>> Thanks, >>> Jens >> All patches are now reviewed and/or acked so I think they can get in for the release. > > This would need a release-ack from Oleksii (I can't seem to find already one). You are right, i do not know why in my mind we already got one. > > As we discussed last week, I am fine with the idea to merge the FFA patches as the feature is tech-preview. But there are some changes in the arm generic code. Do you (or Jens) have an assessment of the risk of the changes? Agree. In my view, the changes are changing the behaviour of some internal functions if an interrupt handler is register for SGI but should not have any impact for other kind of interrupts. As there was nothing before the FF-A driver registering such interrupts, the risk of the changes having any impact on existing configurations not activating FF-A is fairly reduced. @Jens: do you agree with my analysis. I made a text for Oleksii at the beginning of the mail. Cheers Bertrand > > Cheers, > > -- > Julien Grall
Hi all, On Tue, Jun 11, 2024 at 9:09 AM Bertrand Marquis <Bertrand.Marquis@arm.com> wrote: > > Hi Julien and Oleksii, > > @Oleksii: Could we consider having this serie merged for next release ? > > It is a feature that is in tech-preview at the moment and as such should not have any > consequences on existing system unless it is activated explicitly in the Xen configuration. > > There are some changes in the arm common code introducing support to register SGI > interrupt handlers in drivers. As no drivers appart from FF-A is trying to register such > handlers, the risk is minimal for existing systems. > > > > On 10 Jun 2024, at 22:38, Julien Grall <julien@xen.org> wrote: > > > > Hi Bertrand, > > > > On 10/06/2024 16:54, Bertrand Marquis wrote: > >> Hi Jens, > >>> On 10 Jun 2024, at 08:53, Jens Wiklander <jens.wiklander@linaro.org> wrote: > >>> > >>> Hi, > >>> > >>> This patch set adds support for FF-A notifications. We only support > >>> global notifications, per vCPU notifications remain unsupported. > >>> > >>> The first three patches are further cleanup and can be merged before the > >>> rest if desired. > >>> > >>> A physical SGI is used to make Xen aware of pending FF-A notifications. The > >>> physical SGI is selected by the SPMC in the secure world. Since it must not > >>> already be used by Xen the SPMC is in practice forced to donate one of the > >>> secure SGIs, but that's normally not a problem. The SGI handling in Xen is > >>> updated to support registration of handlers for SGIs that aren't statically > >>> assigned, that is, SGI IDs above GIC_SGI_MAX. > >>> > >>> The patch "xen/arm: add and call init_tee_secondary()" provides a hook for > >>> register the needed per-cpu interrupt handler in "xen/arm: ffa: support > >>> notification". > >>> > >>> The patch "xen/arm: add and call tee_free_domain_ctx()" provides a hook for > >>> later freeing of the TEE context. This hook is used in "xen/arm: ffa: > >>> support notification" and avoids the problem with TEE context being freed > >>> while we need to access it when handling a Schedule Receiver interrupt. It > >>> was suggested as an alternative in [1] that the TEE context could be freed > >>> from complete_domain_destroy(). > >>> > >>> [1] https://lore.kernel.org/all/CAHUa44H4YpoxYT7e6WNH5XJFpitZQjqP9Ng4SmTy4eWhyN+F+w@mail.gmail.com/ > >>> > >>> Thanks, > >>> Jens > >> All patches are now reviewed and/or acked so I think they can get in for the release. > > > > This would need a release-ack from Oleksii (I can't seem to find already one). > > You are right, i do not know why in my mind we already got one. > > > > > As we discussed last week, I am fine with the idea to merge the FFA patches as the feature is tech-preview. But there are some changes in the arm generic code. Do you (or Jens) have an assessment of the risk of the changes? > > Agree. > > In my view, the changes are changing the behaviour of some internal functions if an interrupt handler is register for SGI but should not have any impact for other kind of interrupts. > As there was nothing before the FF-A driver registering such interrupts, the risk of the changes having any impact on existing configurations not activating FF-A is fairly reduced. > > @Jens: do you agree with my analysis. Yes, I agree. Cheers, Jens
Hi Bertrand and Julien, On Tue, 2024-06-11 at 07:09 +0000, Bertrand Marquis wrote: > Hi Julien and Oleksii, > > @Oleksii: Could we consider having this serie merged for next release > ? We can consider including it in Xen 4.19 as it has a low impact on existing systems and needs to be explicitly activated: Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> ~ Oleksii > > It is a feature that is in tech-preview at the moment and as such > should not have any > consequences on existing system unless it is activated explicitly in > the Xen configuration. > > There are some changes in the arm common code introducing support to > register SGI > interrupt handlers in drivers. As no drivers appart from FF-A is > trying to register such > handlers, the risk is minimal for existing systems. > > > > On 10 Jun 2024, at 22:38, Julien Grall <julien@xen.org> wrote: > > > > Hi Bertrand, > > > > On 10/06/2024 16:54, Bertrand Marquis wrote: > > > Hi Jens, > > > > On 10 Jun 2024, at 08:53, Jens Wiklander > > > > <jens.wiklander@linaro.org> wrote: > > > > > > > > Hi, > > > > > > > > This patch set adds support for FF-A notifications. We only > > > > support > > > > global notifications, per vCPU notifications remain > > > > unsupported. > > > > > > > > The first three patches are further cleanup and can be merged > > > > before the > > > > rest if desired. > > > > > > > > A physical SGI is used to make Xen aware of pending FF-A > > > > notifications. The > > > > physical SGI is selected by the SPMC in the secure world. Since > > > > it must not > > > > already be used by Xen the SPMC is in practice forced to donate > > > > one of the > > > > secure SGIs, but that's normally not a problem. The SGI > > > > handling in Xen is > > > > updated to support registration of handlers for SGIs that > > > > aren't statically > > > > assigned, that is, SGI IDs above GIC_SGI_MAX. > > > > > > > > The patch "xen/arm: add and call init_tee_secondary()" provides > > > > a hook for > > > > register the needed per-cpu interrupt handler in "xen/arm: ffa: > > > > support > > > > notification". > > > > > > > > The patch "xen/arm: add and call tee_free_domain_ctx()" > > > > provides a hook for > > > > later freeing of the TEE context. This hook is used in > > > > "xen/arm: ffa: > > > > support notification" and avoids the problem with TEE context > > > > being freed > > > > while we need to access it when handling a Schedule Receiver > > > > interrupt. It > > > > was suggested as an alternative in [1] that the TEE context > > > > could be freed > > > > from complete_domain_destroy(). > > > > > > > > [1] > > > > https://lore.kernel.org/all/CAHUa44H4YpoxYT7e6WNH5XJFpitZQjqP9Ng4SmTy4eWhyN+F+w@mail.gmail.com/ > > > > > > > > Thanks, > > > > Jens > > > All patches are now reviewed and/or acked so I think they can get > > > in for the release. > > > > This would need a release-ack from Oleksii (I can't seem to find > > already one). > > You are right, i do not know why in my mind we already got one. > > > > > As we discussed last week, I am fine with the idea to merge the FFA > > patches as the feature is tech-preview. But there are some changes > > in the arm generic code. Do you (or Jens) have an assessment of the > > risk of the changes? > > Agree. > > In my view, the changes are changing the behaviour of some internal > functions if an interrupt handler is register for SGI but should not > have any impact for other kind of interrupts. > As there was nothing before the FF-A driver registering such > interrupts, the risk of the changes having any impact on existing > configurations not activating FF-A is fairly reduced. > > @Jens: do you agree with my analysis. > > I made a text for Oleksii at the beginning of the mail. > > Cheers > > Bertrand > > > > > Cheers, > > > > -- > > Julien Grall > >
Hi, On 11/06/2024 11:36, Oleksii K. wrote: > Hi Bertrand and Julien, > > On Tue, 2024-06-11 at 07:09 +0000, Bertrand Marquis wrote: >> Hi Julien and Oleksii, >> >> @Oleksii: Could we consider having this serie merged for next release >> ? > We can consider including it in Xen 4.19 as it has a low impact on > existing systems and needs to be explicitly activated: > Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> It is now merged. Cheers,
Hi Julien, > On 13 Jun 2024, at 14:44, Julien Grall <julien@xen.org> wrote: > > Hi, > > On 11/06/2024 11:36, Oleksii K. wrote: >> Hi Bertrand and Julien, >> On Tue, 2024-06-11 at 07:09 +0000, Bertrand Marquis wrote: >>> Hi Julien and Oleksii, >>> >>> @Oleksii: Could we consider having this serie merged for next release >>> ? >> We can consider including it in Xen 4.19 as it has a low impact on >> existing systems and needs to be explicitly activated: >> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > > It is now merged. Great, thanks a lot :-) Cheers Bertrand > > Cheers, > > -- > Julien Grall