Hi, On Tue, Apr 23, 2024 at 4:28 PM Julien Grall <jul...@xen.org> wrote: > > Hi Bertrand, > > On 23/04/2024 14:23, Bertrand Marquis wrote: > > Hi Julien, > > > >> On 23 Apr 2024, at 14:37, Bertrand Marquis <bertrand.marq...@arm.com> > >> wrote: > >> > >> Hi Julien, > >> > >>> On 23 Apr 2024, at 13:05, Julien Grall <jul...@xen.org> 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 <jul...@xen.org> 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
