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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

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."

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/