Re: [PATCH v2 09/19] KVM: arm64: vgic-its: Maintain a translation cache per ITS

[Oliver Upton <oliver.upton@linux.dev>]

On Sun, Apr 21, 2024 at 08:47:39PM +0100, Marc Zyngier wrote:
> On Sun, 21 Apr 2024 18:03:24 +0100, Oliver Upton <oliver.upton@linux.dev> wrote:

[...]

> > > Does it mean we could drop this check? And even relax the locking?
> > 
> > I don't think so, a race still exists. For example, Userspace could issue
> > concurrent calls to KVM_SIGNAL_MSI for the same device / event.
> 
> Really? When injecting an MSI, either you hit in the cache or you
> don't. If you don't, you translate the hard way, then try to fit the
> translation in the cache. If if you have a concurrent MSI being
> signalled, whoever wins the "reserve" game wins, and it is "their"
> translation that will make it into the cache.

My understanding of xa_reserve() is that it does nothing and returns 0
if an entry already exists at @index, and only returns an error if an
underlying memory allocation failed. But that could be wrong :)

> At this stage, the locking becomes irrelevant for the purpose of
> avoiding concurrent filling of the cache, because reserving serves as
> a proxy for the store.

The xa_lock() actually isn't relevant either way, as this gets called
under the its_lock. The race arises from vgic_its_check_cache() reading
the translation cache outside of any lock, and one of the threads
winning the race to take the its_lock for the slow path.

xa_reserve() would still succeed on the losing thread (based on my above
assumption) and either needs to re-check the cache or fix the reference
count of whatever entry got evicted.

-- 
Thanks,
Oliver