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." 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. Cheers Bertrand [1] https://developer.arm.com/documentation/den0094/
