Re: [PATCH] irqchip/gic-v4.1: Properly lock VPEs when doing a directLPI invalidation

[Marc Zyngier]

On Thu, 29 Jun 2023 15:52:24 +0100,
Zenghui Yu <yuzenghui@xxxxxxxxxx> wrote:
> 
> Hi Marc,
> 
> On 2023/6/17 15:32, Marc Zyngier wrote:
> > We normally rely on the irq_to_cpuid_[un]lock() primitives to make
> > sure nothing will change col->idx while performing a LPI invalidation.
> 
> "change col_idx while performing a vLPI invalidation"?
> 
> > However, these primitives do not cover VPE doorbells, and we have
> > some open-coded locking for that. Unfortunately, this locking is
> > pretty bogus.
> > 
> > Instead, extend the above primitives to cover VPE doorbells and
> > convert the whole thing to it.
> > 
> > Fixes: f3a059219bc7 ("irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access")
> > Reported-by: Kunkun Jiang <jiangkunkun@xxxxxxxxxx>
> > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> > Cc: Zenghui Yu <yuzenghui@xxxxxxxxxx>
> > Cc: wanghaibin.wang@xxxxxxxxxx
> 
> Reviewed-by: Zenghui Yu <yuzenghui@xxxxxxxxxx>

Thanks!

> 
> Nit: I think the Subject header can be changed to 'irqchip/gic-v4' as
> the bug it fixes only affects GICv4 HW. v4.1 is unaffected.

I'm not so sure.

v4.0 didn't allow direct invalidation of VPE doorbells (we had to use
the fake device hack), except for the HiSi special that implemented
DirectLPI despite the presence of multiple ITSs. It was a violation of
the architecture, but it really saved the day by making invalidations
cheap enough.

Only with v4.1 did we get architectural support for doorbell
invalidation via a register instead of a command for a fake device.

So as far as the architecture is concerned, this should only affect
v4.1. As a side effect, it also affect HiSi's v4.0 implementations.

Or am I missing something?

Cheers,

	M.

-- 
Without deviation from the norm, progress is not possible.