Re: [Xen-devel] [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

[Julien Grall <julien@xxxxxxx>]

Hi,

On 27/03/2020 02:34, Stefano Stabellini wrote:
> It doesn't take into account the latest state of interrupts on
> other vCPUs.
So I think your implementation is going to introduce a deadlock in the 
guest. Let's imagine a guest with 2 vCPUs (A and B) with the following 
setup:
    * The HW SPI 32 is routed to and serviced by vCPU B.
    * vCPU A will routinely wait for any pending SPI 32 to be finished 
before performing a specific task.
In the current form of the vGIC, vCPU B will not exit to Xen when SPI 32 
has been deactivated. Instead, the vCPU will continue to run until an 
unrelated trap happen (I/O emulation, IRQs...). Depending on your setup 
(think NULL scheduler) this may happen in a really long time (or never).
Until the vCPU B exit to Xen, SPI 32 may be considered as active. 
Therefore vCPU A will keep waiting and be block until vCPU B is finally 
trapping in Xen.
My example above is basically a cut down version of 
__synchronize_hardirq() in Linux. In practice, you may be lucky most of 
the times because there will be trap happening time to time. However, it 
also means the task you need to perform on vCPU A will be delayed.
So I would not really bet on the trap here. You have two options:
     1) Force the vCPU to trap when deactivating an interrupt
     2) For the vCPUs to exiting when reading I{S,C}ACTIVER

1) will incur cost on every interrupts which is not great. So I think 
your best option is 2) here.
Cheers,

--
Julien Grall