[PATCH v6 09/49] KVM: arm64: gic-v5: Create and manage VM and VPE tables
Marc Zyngier
maz at kernel.org
Sat Sep 19 02:25:57 PDT 2026
On Fri, 04 Sep 2026 12:38:51 +0100,
Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
>
> GICv5 uses a set of in-memory tables to track and manage VM state.
> These must be allocated by the hypervisor and provided to the IRS.
>
> The VMT (Virtual Machine Table) is a linear or two-level table
> comprising VMT Entries (VMTEs). Each VMTE describes the state for a
> single VM. This state includes things such as the SPI and LPI IST
> configuration (coming in a future commit), an implementation-defined
> VM Descriptor, and a VPE Table (VPET).
>
> The VPET contains one entry per possible VPE ID belonging to a VM. It
> is used to mark a VPE as valid and provide the address of an
> implementation-defined VPE Descriptor (VPED), which the hardware uses
> to track and manage VPE state.
>
> Allocate each VM's VPEDs as a single dense array indexed by vcpu_idx,
> while the VPET remains indexed by the userspace-provided vcpu_id. This
> keeps VPED storage proportional to the number of vCPUs even when their
> IDs are sparse.
>
> The VMT and VPET are shared with the IRS. On systems with a
> non-coherent IRS, cache maintenance operates at cache-line
> granularity, while multiple entries can occupy the same cache line.
> Use a common lock for CPU accesses to these tables and IRS command
> processing so that writing back one entry cannot overwrite an IRS
> update to a neighbouring entry.
>
> The implementation-defined VMD and VPED storage is also visible to the
> IRS. Round these allocations up to whole cache lines to prevent cache
> maintenance from corrupting unrelated slab objects. Initialise the
> storage before publishing its addresses to the IRS.
>
> This commit adds support for allocating the VMT and its descriptor
> backing state, and for managing VMTEs. The VMTEs can be initialised or
> released for reuse. VM IDs are allocated with an IDA, while an XArray
> tracks the host-side allocations associated with populated VMTEs.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff at arm.com>
> ---
> arch/arm64/kvm/Makefile | 2 +-
> arch/arm64/kvm/vgic/vgic-init.c | 2 +
> arch/arm64/kvm/vgic/vgic-v5-tables.c | 681 +++++++++++++++++++++++++++
> arch/arm64/kvm/vgic/vgic-v5-tables.h | 100 ++++
> arch/arm64/kvm/vgic/vgic-v5.c | 19 +
> drivers/irqchip/irq-gic-v5-irs.c | 12 +-
> include/kvm/arm_vgic.h | 4 +
> include/linux/irqchip/arm-gic-v5.h | 14 +-
> 8 files changed, 824 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm64/kvm/vgic/vgic-v5-tables.c
> create mode 100644 arch/arm64/kvm/vgic/vgic-v5-tables.h
>
[...]
The lkp bot is reporting some interesting issues in
202609190650.liMAzwjF-lkp at intel.com:
> + /* Allocate and assign the VM Descriptor, if required. */
> + if (vmt_info->vmd_size != 0) {
> + vmd_alloc_size = round_up(vmt_info->vmd_size,
> + dma_get_cache_alignment());
> + vmd = kzalloc(vmd_alloc_size, GFP_KERNEL);
> + if (!vmd) {
> + ret = -ENOMEM;
> + goto out_fail;
> + }
> +
> + /* Stash the VA so we can free it later */
> + vmi->vmd_base = vmd;
The VMD is dynamically allocated.
> +
> + tmp = FIELD_PREP(GICV5_VMTEL2E_VMD_ADDR,
> + virt_to_phys(vmd) >> GICV5_VMTEL2E_VMD_ADDR_SHIFT);
> + vmte_val0 = tmp;
> + }
> +
> + /*
> + * Allocate and assign the VPE Table.
> + *
> + * First of all, iterate over all vcpus to find the highest VPE ID we
> + * require - we need to ensure that we have enough storage for all
> + * vcpu_id values that userspace has picked and not just the total
> + * number of vcpus. This gives us the number of VPEs required for the
> + * VM.
> + *
> + * Round up the number of VPEs to a whole power of two as we cannot
> + * describe non-powers-of-two in the VMTE field as it conveys the number
> + * of ID bits used and not the number of vPEs. IRS_IDR1.IAFFID_BITS is
> + * encoded as N - 1, so expose at least one VPE ID bit even for a
> + * single-vCPU VM to keep the views consistent.
> + */
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + u16 vpe_id = vgic_v5_vpe_id(vcpu);
> +
> + if (vpe_id > max_vpe_id)
> + max_vpe_id = vpe_id;
> + }
> +
> + nr_cpus = max(2UL, roundup_pow_of_two(max_vpe_id + 1));
> + vmi->vpe_id_bits = fls(nr_cpus) - 1;
> +
> + vpet_alloc_size = round_up((size_t)nr_cpus * sizeof(*vpet),
> + dma_get_cache_alignment());
> + vpet = kzalloc(vpet_alloc_size, GFP_KERNEL);
> + if (!vpet) {
> + ret = -ENOMEM;
> + goto out_fail;
> + }
> +
> + /* Stash the VA so we can free it later */
> + vmi->vpet_base = vpet;
and so is the VPET.
[...]
> diff --git a/arch/arm64/kvm/vgic/vgic-v5-tables.h b/arch/arm64/kvm/vgic/vgic-v5-tables.h
> new file mode 100644
> index 0000000000000..962be0c7cd3f6
> --- /dev/null
> +++ b/arch/arm64/kvm/vgic/vgic-v5-tables.h
> @@ -0,0 +1,100 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2025, 2026 Arm Ltd.
> + */
> +
> +#ifndef __KVM_ARM_VGICV5_TABLES_H__
> +#define __KVM_ARM_VGICV5_TABLES_H__
> +
> +#include <linux/spinlock.h>
> +#include <linux/idr.h>
> +#include <linux/irqchip/arm-gic-v5.h>
> +
> +/* Level 1 Virtual Machine Table Entry */
> +typedef __le64 vmtl1_entry;
> +
> +/* Level 2 Virtual Machine Table Entry */
> +struct vmtl2_entry {
> + __le64 val[4];
> +};
> +
> +/* Virtual PE Table Entry */
> +typedef __le64 vpe_entry;
> +
> +struct vgic_v5_vm_info {
> + void __iomem *vmd_base;
> + vpe_entry __iomem *vpet_base;
But pointers to allocated memory cannot be __iomem, as this qualifies
MMIO registers.
I'll queue the change below on top.
M.
diff --git a/arch/arm64/kvm/vgic/vgic-v5-tables.h b/arch/arm64/kvm/vgic/vgic-v5-tables.h
index b2ffbe68c05b4..89096926563f7 100644
--- a/arch/arm64/kvm/vgic/vgic-v5-tables.h
+++ b/arch/arm64/kvm/vgic/vgic-v5-tables.h
@@ -23,8 +23,8 @@ struct vmtl2_entry {
typedef __le64 vpe_entry;
struct vgic_v5_vm_info {
- void __iomem *vmd_base;
- vpe_entry __iomem *vpet_base;
+ void *vmd_base;
+ vpe_entry *vpet_base;
void *vped_base;
u8 vpe_id_bits;
--
Jazz isn't dead. It just smells funny.
More information about the linux-arm-kernel
mailing list