Re: [XEN PATCH v6 0/7] FF-A notifications

["Oleksii K." <oleksii.kurochko@xxxxxxxxx>]

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@xxxxxxxxx>

~ 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@xxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/
> > > > 
> > > > 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
> 
>