Re: [PATCH 1/4] KVM: arm64: vgic-its: Free the caches when GITS_BASER changes

[Fuad Tabba]

Hi Eric, Marc,

On Thu, 20 Aug 2026 at 11:34, Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> Hi Eric,
>
> On Thu, 20 Aug 2026 11:09:06 +0100,
> Eric Auger <eauger@xxxxxxxxxx> wrote:
> >
> > Hi Fuad,
> >
> > On 8/19/26 12:28 PM, Fuad Tabba wrote:
> > > A guest that disables the ITS and re-points or shrinks GITS_BASER<n>
> > > with VALID still set keeps the devices and collections it mapped
> > > against the old table, as KVM frees them only when VALID is cleared.
> > > The table format is not architected, so a write with a different value
> > > is allowed to lose what it describes. Free the list whenever the
> > I don't really get "a write with a different value is allowed to lose
> > what it describes". A write at which place, in the collection table?
>
> A write to the GITS_BASERn register describing the pointer to the
> collection table.
>
> The additional clarification is that because the *content* of the
> table is IMPDEF, if you point the ITS to a different location or size
> in memory, then there is no guarantee that the caches (the KVM
> internal data structures) are up to date. In this case, the proposed
> course of action is to invalidate the caches and start afresh.

My sentence should have said what the write was to. I'll spell it out
in v2 along the lines of your reply.

...

> > One question: There is no vgic_its_invalidate_cache() in the function.
> > Is it OK?
>
> Probably not. We should make sure that the translation cache is gone
> as well so that we retranslate and avoid signalling LPIs that have
> undergone such invalidation. Thanks for spotting this.

I'll add it in v2. The device branch already gets it through
vgic_its_free_device(), but the collection branch doesn't.

Thank you both,
/fuad

> > Besides out of curiosity, why don't we go further and remove ite entries
> > that refer to removed collections in vgic_its_free_collection()?
>
> The current policy is to keep the LPI alive as long as it is
> mapped. The only thing is that we can't signal it, obviously. But it
> would be legal to drop them altogether, only more work.
>
> An additional question is whether we should consider doing a reload of
> the collection table or not. I'm not keen on it, but I can also see
> how a guest could want to do this. Feels a bit over the top though.
>
> Thanks,
>
>         M.
>
> --
> Jazz isn't dead. It just smells funny.