Hi Leif & Ard,

You are correct. The main use case is around silicon testing.

There is currently no UEFI or PI spec around such functionality though.

Manipulating pending interrupts might be a far fetch, but can we fix
"ArmGicSendSgiTo" function on GIC v3 and v4? It is declared as a public
interface provided through ArmGicLib, but the fact that it does not work
on GIC v3 and v4 without any notes seems confusing and misleading.

Please let me know if you have other suggestions.

Regards,
Kun

On 8/3/2023 10:02 AM, Leif Lindholm wrote:
> On 2023-08-03 16:33, Ard Biesheuvel wrote:
>> On Wed, 26 Jul 2023 at 20:45, Kun Qin <kuqin12@gmail.com> wrote:
>>>
>>> Hi Ard,
>>>
>>> Our current use case is around AP core suspension and wake-ups.
>>>
>>> The program can suspend the secondary cores through PSCI interfaces
>>> (after powering
>>> them on). BSP can then wake up the suspended cores through SGI on 
>>> demand.
>>>
>>
>> The use of PSCI is already dubious in the context of UEFI - combining
>> it with the use of SGIs for communication between cores seems like a
>> slippery slope I don't think we should be going down.
>
> Well, UEFI has no concept of multiple cores, so I don't think there's 
> anything fishy about using PSCI to bring up/down APs. But I agree 
> adding interrupt support, not considered by either UEFI nor PI, feels 
> off.
>
> What is the fundamental use-case? (Pre-)silicon testing?
>
> /
>     Leif
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107555): https://edk2.groups.io/g/devel/message/107555
Mute This Topic: https://groups.io/mt/100337221/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-