Re: [PATCH v4 10/48] KVM: arm64: gic-v5: Introduce guest IST alloc and management
Fuad Tabba <[email protected]>
| Newsgroups | dev.linux.lists.sashiko-reviews,dev.linux.lists.kvmarm,org.kernel.vger.kvm |
|---|---|
| Message-ID | <CA+EHjTz0byw1LJDnqJGsPgOYz-pwyyY_u5S_44CbKGAfKnQkgQ@mail.gmail.com> |
On Fri, 24 Jul 2026 at 12:29, <[email protected]> wrote: ... > - [High] Missing `GICV5_VMTEL2E_IST_VALID` bit leaves IST configurations invalid. Replying to this one because I was reading about this today, and thought it was tricky. This is a false positive (will teach Sashiko/review-prompts about the GICv5 once this series goes in). I do not think this one holds, and I would not apply it. The IRS writes that bit itself. `vgic_v5_vmte_assign_ist()` populates the IST section and then issues `SPI_VIST_MAKE_VALID` / `LPI_VIST_MAKE_VALID`, which is the `IRS_VMAP_VISTR` write, and the IRS sets the section's valid bit in response to it (from the spec). Software setting that bit itself in an L2 entry belonging to a valid VM is UNPREDICTABLE. KVM makes the VM valid before it ever assigns an IST, in `vgic_v5_init()`, so it is always on that path. There is a separate case where software does write the bit, when the L2 entry is populated before the VM becomes valid, but that is not the sequence here. Same reasoning applies to the level 1 VM table entry, where the IRS sets `L1_VMTE.VALID` in response to `IRS_VMAP_L2_VMTR`. Cheers, /fuad