Re: [XEN PATCH v2 4/5] xen/arm: allow dynamically assigned SGI handlers

[Jens Wiklander <jens.wiklander@xxxxxxxxxx>]

Hi,

On Tue, Apr 23, 2024 at 4:28 PM Julien Grall <julien@xxxxxxx> wrote:
>
> Hi Bertrand,
>
> On 23/04/2024 14:23, Bertrand Marquis wrote:
> > Hi Julien,
> >
> >> On 23 Apr 2024, at 14:37, Bertrand Marquis <Bertrand.Marquis@xxxxxxx> 
> >> wrote:
> >>
> >> Hi Julien,
> >>
> >>> On 23 Apr 2024, at 13:05, Julien Grall <julien@xxxxxxx> wrote:
> >>>
> >>>
> >>>
> >>> On 23/04/2024 10:35, Jens Wiklander wrote:
> >>>> Hi Julien,
> >>>
> >>> Hi Jens,
> >>>
> >>>> On Mon, Apr 22, 2024 at 12:57 PM Julien Grall <julien@xxxxxxx> wrote:
> >>>>>
> >>>>> Hi Jens,
> >>>>>
> >>>>> On 22/04/2024 08:37, Jens Wiklander wrote:
> >>>>>> Updates so request_irq() can be used with a dynamically assigned SGI 
> >>>>>> irq
> >>>>>> as input. This prepares for a later patch where an FF-A schedule
> >>>>>> receiver interrupt handler is installed for an SGI generated by the
> >>>>>> secure world.
> >>>>>
> >>>>> I would like to understand the use-case a bit more. Who is responsible
> >>>>> to decide the SGI number? Is it Xen or the firmware?
> >>>>>
> >>>>> If the later, how can we ever guarantee the ID is not going to clash
> >>>>> with what the OS/hypervisor is using? Is it described in a
> >>>>> specification? If so, please give a pointer.
> >>>> The firmware decides the SGI number. Given that the firmware doesn't
> >>>> know which SGIs Xen is using it typically needs to donate one of the
> >>>> secure SGIs, but that is transparent to Xen.
> >>>
> >>> Right this is my concern. The firmware decides the number, but at the 
> >>> same time Xen thinks that all the SGIs are available (AFAIK there is only 
> >>> one set).
> >>>
> >>> What I would like to see is some wording from a spec indicating that the 
> >>> SGIs ID reserved by the firmware will not be clashing with the one used 
> >>> by Xen.
> >>
> >> The idea is that the only SGI reserved for secure are used by the secure 
> >> world (in fact it is the SPMC in the secure world who tells us which SGI 
> >> it will generate).
> >> So in theory that means it will always use an SGI between 8 and 15.
> >>
> >> Now it could make sense in fact to check that the number returned by the 
> >> firmware (or SPMC) is not clashing with Xen as it is a recommendation in 
> >> the spec and
> >> in fact an implementation might do something different.
> >>
> >> Right now there is no spec that will say that it will never clash with the 
> >> one used by Xen as the FF-A spec is not enforcing anything here so it 
> >> would be a good idea
> >> to check and disable FF-A with a proper error message if this happens.
> >
> >
> > After some more digging here is what is recommended by Arm in the Arm Base 
> > System Architecture v1.0C [1]:
> >
> > "The system shall implement at least eight Non-secure SGIs, assigned to 
> > interrupt IDs 0-7."
>
> Thanks! Can we provide a link to the specification in the commit message?

Sure, I'll add a link.

>
> >
> > So basically as long as Xen is using SGIs 0-7 it is safe as those shall 
> > never be used by the secure world.
> > Now i do agree that we should check that whatever is returned by the 
> > firmware is not conflicting with what
> > is used by Xen.
> +1.

That makes sense, I'll add a check.

Thanks,
Jens