[PATCH v4 10/48] KVM: arm64: gic-v5: Introduce guest IST alloc and management
Fuad Tabba
fuad.tabba at linux.dev
Mon Jul 27 10:55:33 PDT 2026
Hi Sascha,
On Fri, 24 Jul 2026 at 11:52, Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
...
> +static int vgic_v5_alloc_linear_ist(struct kvm *kvm, bool spi_ist,
> + unsigned int id_bits, unsigned int istsz)
> +{
> + const size_t n = id_bits + 1 + istsz;
...
> + l1sz = BIT(n + 1);
> + ist = kzalloc(l1sz, GFP_KERNEL_ACCOUNT);
...
> +static int vgic_v5_alloc_l1_ist(struct kvm *kvm, unsigned int id_bits,
> + unsigned int istsz, unsigned int l2sz)
> +{
> + const size_t n = max(5, id_bits - ((10 - istsz) + (2 * l2sz)) + 3 - 1);
> + u32 vm_id = vgic_v5_vm_id(kvm);
> + const u32 l1_size = BIT(n + 1);
I think the linear path might be missing the floor that this one
applies. The host driver keeps it on its own linear path too:
`gicv5_irs_init_ist_linear()` uses `n = max(5, lpi_id_bits + 1 +
istsz)`.
Without the floor the allocation is under 64 bytes whenever `id_bits +
1 + istsz < 5`, and `vgic_v5_ist_istsz()` gives an `istsz` of 0 on a
host without metadata support. `ARCH_KMALLOC_MINALIGN` is 8 on arm64,
so a 4 to 32 byte allocation is not necessarily 64-byte aligned, and
`vgic_v5_vmte_assign_ist()` rejects that against
`GICV5_VMTEL2E_IST_ADDR`. It depends on where the slab places the
allocation, so it is intermittent rather than reliable.
The rejection also logs with an unratelimited `kvm_err()`, on a path
the guest can drive repeatedly.
This needs the host IRS to report a `MIN_LPI_ID_BITS` low enough to
reach it, since `vgic_v5_ist_cfgr_valid()` rejects an `lpi_id_bits`
below `irs->idr2.min_lpi_id_bits`.
Cheers,
/fuad
More information about the linux-arm-kernel
mailing list