linux-next.git/include/kvm, branch master

KVM: arm64: gic-v5: Handle userspace accesses to IRS MMIO region

2026-09-14T09:49:09+00:00

As part of saving and restoring the state of a GICv5-based system, userspace must save and restore the IRS MMIO registers. These include important information such as the guest IST configuration, and KVM must present consistent state to the guest after migration. Introduce KVM_DEV_ARM_VGIC_GRP_IRS_REGS and provide accessors to read and write the virtual IRS register state. This is modelled on the GICv3 ITS register interface, as the migration requirements are broadly the same. Reuse the guest MMIO handlers where userspace and guest accesses have the same semantics. Add userspace-specific handling where restoring a register image must not trigger the operation associated with a guest MMIO write. Validate restored ID register fields against the capabilities KVM and the host can support. Restore the emulated IST configuration without allocating or freeing a host IST, and report operation status registers as idle. Accept writes to IRS_SPI_CFGR, IRS_IIDR, and IRS_AIDR without changing their state, allowing userspace to replay the values it previously read. Restoring IRS_IST_BASER.Valid recreates the guest-visible configuration, but the host LPI IST cannot be allocated until userspace supplies its contents. Track this as a pending LPI IST restore and reject guest entry until userspace restores the IST through KVM_DEV_ARM_VGIC_GRP_IST. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-33-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Mask per-vCPU PPI state in vgic_v5_finalize_ppi_state()

2026-09-14T09:49:09+00:00

Only a subset of the possible PPIs are exposed to a guest when running with a vGICv5. First of all, only the architected PPIs are considered by KVM. Secondly, only a set of those is exposed to a guest: those corresponding to devices that KVM emulates, such as the timers and PMU, and the GICv5 SW_PPI. The finalisation of exposed PPIs happens on first vCPU run, as this is the first time when the full set of exposed devices is known. At this stage a mask is calculated, and this mask is applied both to hide non-exposed PPI state from the guest and to reduce overhead when iterating over the PPIs. While preparing userspace access to the GICv5 system registers, it became apparent that restoring the GICv5 PPI registers can result in a mismatch between the state supplied by userspace and the state KVM intends to expose. Userspace can provide Enable, Active, and Pending state for PPIs that KVM has chosen to hide from the guest. Userspace must restore PPI state before any vCPU runs. The userspace access path added subsequently enforces this ordering. Rework vgic_v5_finalize_ppi_state() to calculate the mask of exposed PPIs and clear any state belonging to non-exposed PPIs. This ensures that only the state KVM intends to expose is visible to the guest. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-31-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic: Introduce set_pending_state() to irq_ops

2026-09-14T09:49:08+00:00

There are times, such as with GICv5 SPIs and LPIs, where the hardware itself manages parts of the interrupt lifecycle. This means that pending state can be directly communicated to the hardware instead of being represented only in the VGIC shadow state. In order to accommodate cases where the hardware handles pending state directly, add a new set_pending_state() function pointer to irq_ops. The intent is for this to be used after the VGIC shadow pending state has changed, allowing the backend to mirror the updated state into hardware. This new function is plumbed into kvm_vgic_inject_irq(), and is only called if irq_ops are provided and this function pointer is explicitly set. In the general case, this has no effect. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-27-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Register the IRS IODEV

2026-09-14T09:49:08+00:00

Now that we have an emulated IRS, it needs to be registered, which ensures that guest accesses to the MMIO regions handled by the device are handled appropriately in KVM. Therefore, as part of vgic_map_resources, the GICv5 IRS IODEV is registered. If the address for the IRS is not provided, bail out reporting an error - this is not a supported config. As part of this change, expose setting the address of the emulated IRS via KVM_VGIC_V5_ADDR_TYPE_IRS to userspace. Also allow userspace to set the number of SPIs handled by the emulated GICv5 implementation, using a GICv5-specific SPI count rather than the legacy total interrupt count. Limit the configurable range to 32 through 1024 SPIs, in multiples of 32. KVM keeps one struct vgic_irq per SPI in a physically contiguous allocation, and allowing the full 16-bit KVM_IRQ_LINE SPI namespace would make that allocation exceed KMALLOC_MAX_SIZE on common arm64 configurations. The default routing has one IRQCHIP route per configured SPI, so size the common IRQ routing table for the largest GICv5 configuration. The model-specific routing validation retains the 988-pin limit for GICv2 and GICv3. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-23-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Add GICv5 IRS IODEV and MMIO emulation

2026-09-14T09:49:08+00:00

In order to properly support GICv5-based VMs in KVM, emulate the CONFIG_FRAME for a virtual IRS. This emulation needs to handle guest accesses to the MMIO region and mimic the behaviour of a real IRS. Introduce an IODEV for the GICv5 IRS and an associated initialisation function that sets up the SPIs and initial IRS state. The MMIO emulation allows the guest to query the IRS_IDx registers, manipulate SPIs, configure ISTs, and so forth. Allow 32-bit accesses to the 64-bit IRS registers in addition to 64-bit accesses. Reconstruct IRS_IST_BASER for reads and merge partial writes so that updating either word preserves the other half. The emulation tracks selector state across MMIO accesses. For example, a guest writes IRS_PE_SELR to select a PE by IAFFID. This is the VPE ID for a VM, but the guest does not know this. If the guest reads IRS_PE_STATUSR, KVM checks whether that IAFFID selects a valid VPE and sets the V bit accordingly. IRS_PE_CR0 is accepted as write-ignored because KVM does not support 1-of-N routing. The same selector and status register model is exposed for SPIs. Track the state of IRS_CR0.IRSEN and introduce KVM_REQ_RELOAD_GICv5 to reload the GICv5 context of running vCPUs when it changes. Only make the request when the enable state changes, avoiding unnecessary IPIs for writes that leave it unchanged. The LPI IST requires KVM to perform actions on behalf of the guest. Treat changes to IRS_IST_BASER.Valid as the lifetime of the guest's IST. On an Invalid-to-Valid transition, validate IRS_IST_CFGR, allocate a shadow host IST, and assign it to the physical IRS through the VMTE. On a Valid-to-Invalid transition, invalidate and free the host IST. Ignore guest address changes while the BASER remains valid, and prevent changes to IRS_IST_CFGR during that time. As far as the guest is concerned, the IST memory it provided is being used by the hardware, but the physical IRS uses the host shadow IST instead. This change provides the core IRS IODEV and MMIO emulation, but does not plumb the device into the rest of KVM yet. The CoreSight identification registers are added separately. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-21-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Add IRS IODEV support to MMIO handlers

2026-09-14T09:49:08+00:00

In order to support proper VMs (that support more than just PPIs) for GICv5, it is important to emulate the GICv5 IRS too. The IRS includes an MMIO interface which is used to interact with and configure the IRS. As part of providing the emulated IRS MMIO interface in KVM, extend enum iodev_type to include a GICv5 IRS device, and extend the MMIO code to handle reads and writes to that type of IO device. This will allow the creation of a GICv5 IRS IO Device in KVM. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-19-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Introduce struct vgic_v5_irs and IRS base address

2026-09-14T09:49:08+00:00

In order to properly emulate the operation of the IRS from KVM, we require storage for the MMIO register state. This change introduces struct vgic_v5_irs, and adds a pointer to it to the struct vgic_dist. This new data structure contains the storage for IRS MMIO state that is required for emulating the MMIO interface in KVM. This provides persistent storage, and a way to track data across MMIO writes, e.g., selecting an SPI and updating the configuration of it is two MMIO writes. Note that only a pointer to the data structure is added to struct vgic_dist as this new structure is very large, and hence it makes sense to dynamically allocate it and just provide a pointer to retrieve it in struct vgic_dist. In addition to adding a structure to store the MMIO state for the IRS, we add the base address in GPA space to struct vgic_v5_irs. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-18-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Add resident/non-resident hyp calls

2026-09-14T09:49:08+00:00

GICv5 introduces the concept of VPE residency - a VPE can be either resident or non-resident. When the VPE is resident, the IRS is allowed to select interrupts that target that VPE (or the VM) as the HPPI (Highest Priority Pending Interrupt). As the IRS handles both SPIs and LPIs, these will only be picked as the IRS's HPPI when a VPE is resident. A GICv5 VPE is made resident by writing ICH_CONTEXTR_EL2 with ICH_CONTEXTR_EL2.V set, together with valid VM and VPE IDs. This informs the IRS that a specific VPE is running, and that it can begin HPPI selection for that VPE. Making a VPE non-resident (by making the ICH_CONTEXTR_EL2 invalid) informs the IRS that the VPE is no longer running, and it stops HPPI selection for it. This change introduces two new hyp calls - one to make a VPE resident and its counterpart to make a VPE non-resident. As part of making a VPE resident, the resulting ICH_CONTEXTR_EL2.F bit is checked to catch residency faults. Such a fault indicates a broken VM/VPE setup, so warn and mark the VM dead. Both of these new hypercalls are explicitly no-ops with pKVM as we currently don't support the combination of GICv5 and pKVM. Furthermore, this change extends vgic_v5_load() and vgic_v5_put() to make the VPEs resident and non-resident, respectively. Hence, the VPE is considered resident for the entire load-to-put interval. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-16-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Set up VMTEs and VPE doorbells

2026-09-14T09:49:08+00:00

A GICv5 VM needs a VM table entry before it can use SPIs and LPIs, which are backed by the host IRS. The VM table itself is created at probe time, but each VM still needs to claim and populate one VMTE before it can use those interrupts. VPE doorbells are allocated from the host LPI irq domain. Without that domain, KVM cannot issue IRS commands or receive doorbell wakeups. Fail the GICv5 KVM probe if the host driver did not create an LPI domain. Allocate a VM ID during vgic_v5_init(). The VM ID is also the index into the VM table, so allocating it selects the VMTE slot that will be used for the lifetime of the VM. Create a per-VM VPE doorbell irq domain, allocate one doorbell interrupt per vCPU, request the interrupts, and keep the doorbell IRQ number in the vCPU's GICv5 state. The doorbell handler marks the VPE doorbell as fired, raises KVM_REQ_IRQ_PENDING, and kicks the target vCPU so that KVM can re-evaluate pending interrupt state. The doorbell domain indexes its interrupts using the dense vcpu_idx, while GICv5 uses the userspace-provided vcpu_id as the VPE ID. Store a backpointer to the VM and use it to resolve the vCPU before issuing VPE-specific IRS commands. This preserves the userspace VPE ID when vCPU IDs are sparse. With the VM ID and doorbells in place, initialise the VMTE backing state, including the VM descriptor, VPE table, and preallocated VPED storage. The doorbells have to exist before making the VMTE valid, as they provide the IRQ-side conduit used by the IRS commands. Make the VMTE valid via the IRS, then populate the VPETE for each vCPU. Add vgic_v5_teardown() to unwind the state in the reverse order. Make the VMTE invalid, clear the per-vCPU VPETEs, release the VMTE backing state, free the doorbell IRQs and irq domain, and finally release the VM ID so that the VMTE slot can be reused by a later VM. If invalidating the VMTE, clearing a VPETE, or releasing the VMTE fails, still free the software doorbells and domain, but keep the VM ID allocated so that the VMTE slot is not reused while hardware-visible state may remain. On init failure, call the same teardown path so that partially created state is unwound consistently. As part of resetting vCPUs, mark them as valid in the VM's VPE table. This informs the IRS that a specific VPE may be made resident. Without this, the IRS will treat the VPE as invalid. Also introduce vgic_v5_send_command(), a wrapper around the VPE doorbells. It takes a struct kvm_vcpu pointer and the command to run, and invokes the function bound to that command through the vCPU's doorbell. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-15-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: vgic: Enforce model-specific vCPU limits

2026-09-14T09:49:07+00:00

A GICv5 host with FEAT_GCIE_LEGACY can expose either a native vGICv5 or a vGICv3 device. These models do not necessarily have the same vCPU limit: the native GICv5 limit is probed from the IRS VPE capacity, while the GICv3 limit remains the fixed KVM vGICv3 limit. Keep the IRS-derived limit separately for vGICv5 creation. The pre-VGIC KVM_CAP_MAX_VCPUS value continues to expose the largest limit among the still-selectable models, and kvm_vgic_create() clamps the VM to the limit of the VGIC model userspace actually selected. Userspace can create vCPUs before creating a VGIC. Hence, checking only the number of existing vCPUs after reducing the limit is not sufficient. For example, a single vCPU with ID 500 passes the GICv2 count limit even though GICv2 can represent only eight target CPUs. The GICv2 code subsequently uses the vCPU ID in target and SGI source masks, leading to shifts beyond the width of the operand. GICv5 has a similar requirement because the userspace-provided vcpu_id is used as the index into the VPET. This means that the vcpu_id also represents the IAFFID for a VPE, and therefore is visible to the guest. After selecting the model-specific limit, validate every existing vCPU ID against it. KVM_CREATE_VCPU already enforces the same limit for vCPUs created after the VGIC, making the result independent of creation order. Link: https://lore.kernel.org/r/20260807133051.15D381F000E9@smtp.kernel.org Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260904113404.4051341-13-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier