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?


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.

Cheers,

--
Julien Grall

Reply via email to