Re: [PATCH v4 10/48] KVM: arm64: gic-v5: Introduce guest IST alloc and management

Hi Fuad,

On Mon, 2026-07-27 at 18:55 +0100, Fuad Tabba wrote:
> Hi Sascha,
> 
> On Fri, 24 Jul 2026 at 11:52, Sascha Bischoff
> <[email protected]> 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)`.

Ah, yes. Right you are! Thanks for catching that one. I've added in the
same lower limit.

> 
> 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.

Which, frankly, is worse than it consistently failing IMO, so thanks
again for spotting that one.

> 
> The rejection also logs with an unratelimited `kvm_err()`, on a path
> the guest can drive repeatedly.

Yeah, that's not ideal. I've kept the error in as things really have
broken in this case, but I've made it a pr_err_ratelimited() instead.

> 
> 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`.

Given that there's not a lower limit for the field, it is worth
guarding against. Just in case.

> 
> Cheers,
> /fuad

Thanks,
Sascha