lwn.git/arch/arm64/kvm/vgic/vgic.c, branch docs-fixes

KVM: arm64: gic-v5: Support GICv5 interrupts with KVM_IRQ_LINE

2026-03-19T18:21:28+00:00

Interrupts under GICv5 look quite different to those from older Arm GICs. Specifically, the type is encoded in the top bits of the interrupt ID. Extend KVM_IRQ_LINE to cope with GICv5 PPIs and SPIs. The requires subtly changing the KVM_IRQ_LINE API for GICv5 guests. For older Arm GICs, PPIs had to be in the range of 16-31, and SPIs had to be 32-1019, but this no longer holds true for GICv5. Instead, for a GICv5 guest support PPIs in the range of 0-127, and SPIs in the range 0-65535. The documentation is updated accordingly. The SPI range doesn't cover the full SPI range that a GICv5 system can potentially cope with (GICv5 provides up to 24-bits of SPI ID space, and we only have 16 bits to work with in KVM_IRQ_LINE). However, 65k SPIs is more than would be reasonably expected on systems for years to come. In order to use vgic_is_v5(), the kvm/arm_vgic.h header is added to kvm/arm.c. Note: As the GICv5 KVM implementation currently doesn't support injecting SPIs attempts to do so will fail. This restriction will by lifted as the GICv5 KVM support evolves. Co-authored-by: Timothy Hayes Signed-off-by: Timothy Hayes Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-28-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: Introduce set_direct_injection irq_op

2026-03-19T18:21:28+00:00

GICv5 adds support for directly injected PPIs. The mechanism for setting this up is GICv5 specific, so rather than adding GICv5-specific code to the common vgic code, we introduce a new irq_op. This new irq_op is intended to be used to enable or disable direct injection for interrupts that support it. As it is an irq_op, it has no effect unless explicitly populated in the irq_ops structure for a particular interrupt. The usage is demonstracted in the subsequent change. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260319154937.3619520-26-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Check for pending PPIs

2026-03-19T18:21:28+00:00

This change allows KVM to check for pending PPI interrupts. This has two main components: First of all, the effective priority mask is calculated. This is a combination of the priority mask in the VPEs ICC_PCR_EL1.PRIORITY and the currently running priority as determined from the VPE's ICH_APR_EL1. If an interrupt's priority is greater than or equal to the effective priority mask, it can be signalled. Otherwise, it cannot. Secondly, any Enabled and Pending PPIs must be checked against this compound priority mask. The reqires the PPI priorities to by synced back to the KVM shadow state on WFI entry - this is skipped in general operation as it isn't required and is rather expensive. If any Enabled and Pending PPIs are of sufficient priority to be signalled, then there are pending PPIs. Else, there are not. This ensures that a VPE is not woken when it cannot actually process the pending interrupts. As the PPI priorities are not synced back to the KVM shadow state on every guest exit, they must by synced prior to checking if there are pending interrupts for the guest. The sync itself happens in vgic_v5_put() if, and only if, the vcpu is entering WFI as this is the only case where it is not planned to run the vcpu thread again. If the vcpu enters WFI, the vcpu thread will be descheduled and won't be rescheduled again until it has a pending interrupt, which is checked from kvm_arch_vcpu_runnable(). Signed-off-by: Sascha Bischoff Reviewed-by: Joey Gouly Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-24-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Implement PPI interrupt injection

2026-03-19T18:21:28+00:00

This change introduces interrupt injection for PPIs for GICv5-based guests. The lifecycle of PPIs is largely managed by the hardware for a GICv5 system. The hypervisor injects pending state into the guest by using the ICH_PPI_PENDRx_EL2 registers. These are used by the hardware to pick a Highest Priority Pending Interrupt (HPPI) for the guest based on the enable state of each individual interrupt. The enable state and priority for each interrupt are provided by the guest itself (through writes to the PPI registers). When Direct Virtual Interrupt (DVI) is set for a particular PPI, the hypervisor is even able to skip the injection of the pending state altogether - it all happens in hardware. The result of the above is that no AP lists are required for GICv5, unlike for older GICs. Instead, for PPIs the ICH_PPI_* registers fulfil the same purpose for all 128 PPIs. Hence, as long as the ICH_PPI_* registers are populated prior to guest entry, and merged back into the KVM shadow state on exit, the PPI state is preserved, and interrupts can be injected. When injecting the state of a PPI the state is merged into the PPI-specific vgic_irq structure. The PPIs are made pending via the ICH_PPI_PENDRx_EL2 registers, the value of which is generated from the vgic_irq structures for each PPI exposed on guest entry. The queue_irq_unlock() irq_op is required to kick the vCPU to ensure that it seems the new state. The result is that no AP lists are used for private interrupts on GICv5. Prior to entering the guest, vgic_v5_flush_ppi_state() is called from kvm_vgic_flush_hwstate(). This generates the pending state to inject into the guest, and snapshots it (twice - an entry and an exit copy) in order to track any changes. These changes can come from a guest consuming an interrupt or from a guest making an Edge-triggered interrupt pending. When returning from running a guest, the guest's PPI state is merged back into KVM's vgic_irq state in vgic_v5_merge_ppi_state() from kvm_vgic_sync_hwstate(). The Enable and Active state is synced back for all PPIs, and the pending state is synced back for Edge PPIs (Level is driven directly by the devices generating said levels). The incoming pending state from the guest is merged with KVM's shadow state to avoid losing any incoming interrupts. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-21-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic: Introduce queue_irq_unlock to irq_ops

2026-03-19T18:21:28+00:00

There are times when the default behaviour of vgic_queue_irq_unlock() is undesirable. This is because some GICs, such a GICv5 which is the main driver for this change, handle the majority of the interrupt lifecycle in hardware. In this case, there is no need for a per-VCPU AP list as the interrupt can be made pending directly. This is done either via the ICH_PPI_x_EL2 registers for PPIs, or with the VDPEND system instruction for SPIs and LPIs. The vgic_queue_irq_unlock() function is made overridable using a new function pointer in struct irq_ops. vgic_queue_irq_unlock() is overridden if the function pointer is non-null. This new irq_op is unused in this change - it is purely providing the infrastructure itself. The subsequent PPI injection changes provide a demonstration of the usage of the queue_irq_unlock irq_op. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-20-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Implement GICv5 load/put and save/restore

2026-03-19T18:21:28+00:00

This change introduces GICv5 load/put. Additionally, it plumbs in save/restore for: * PPIs (ICH_PPI_x_EL2 regs) * ICH_VMCR_EL2 * ICH_APR_EL2 * ICC_ICSR_EL1 A GICv5-specific enable bit is added to struct vgic_vmcr as this differs from previous GICs. On GICv5-native systems, the VMCR only contains the enable bit (driven by the guest via ICC_CR0_EL1.EN) and the priority mask (PCR). A struct gicv5_vpe is also introduced. This currently only contains a single field - bool resident - which is used to track if a VPE is currently running or not, and is used to avoid a case of double load or double put on the WFI path for a vCPU. This struct will be extended as additional GICv5 support is merged, specifically for VPE doorbells. Co-authored-by: Timothy Hayes Signed-off-by: Timothy Hayes Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-18-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic: Introduce interrupt type helpers

2026-03-19T18:21:27+00:00

GICv5 has moved from using interrupt ranges for different interrupt types to using some of the upper bits of the interrupt ID to denote the interrupt type. This is not compatible with older GICs (which rely on ranges of interrupts to determine the type), and hence a set of helpers is introduced. These helpers take a struct kvm*, and use the vgic model to determine how to interpret the interrupt ID. Helpers are introduced for PPIs, SPIs, and LPIs. Additionally, a helper is introduced to determine if an interrupt is private - SGIs and PPIs for older GICs, and PPIs only for GICv5. Additionally, vgic_is_v5() is introduced (which unsurpisingly returns true when running a GICv5 guest), and the existing vgic_is_v3() check is moved from vgic.h to arm_vgic.h (to live alongside the vgic_is_v5() one), and has been converted into a macro. The helpers are plumbed into the core vgic code, as well as the Arch Timer and PMU code. There should be no functional changes as part of this change. Signed-off-by: Sascha Bischoff Reviewed-by: Joey Gouly Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-10-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: vgic: Split out mapping IRQs and setting irq_ops

2026-03-19T18:21:27+00:00

Prior to this change, the act of mapping a virtual IRQ to a physical one also set the irq_ops. Unmapping then reset the irq_ops to NULL. So far, this has been fine and hasn't caused any major issues. Now, however, as GICv5 support is being added to KVM, it has become apparent that conflating mapping/unmapping IRQs and setting/clearing irq_ops can cause issues. The reason is that the upcoming GICv5 support introduces a set of default irq_ops for PPIs, and removing this when unmapping will cause things to break rather horribly. Split out the mapping/unmapping of IRQs from the setting/clearing of irq_ops. The arch timer code is updated to set the irq_ops following a successful map. The irq_ops are intentionally not removed again on an unmap as the only irq_op introduced by the arch timer only takes effect if the hw bit in struct vgic_irq is set. Therefore, it is safe to leave this in place, and it avoids additional complexity when GICv5 support is introduced. Signed-off-by: Sascha Bischoff Link: https://patch.msgid.link/20260319154937.3619520-6-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tail

2026-03-07T21:45:58+00:00

Valentine reports that their guests fail to boot correctly, losing interrupts, and indicates that the wrong interrupt gets deactivated. What happens here is that if the maintenance interrupt is slow enough to kick us out of the guest, extra interrupts can be activated from the LRs. We then exit and proceed to handle EOIcount deactivations, picking active interrupts from the AP list. But we start from the top of the list, potentially deactivating interrupts that were in the LRs, while EOIcount only denotes deactivation of interrupts that are not present in an LR. Solve this by tracking the last interrupt that made it in the LRs, and start the EOIcount deactivation walk *after* that interrupt. Since this only makes sense while the vcpu is loaded, stash this in the per-CPU host state. Huge thanks to Valentine for doing all the detective work and providing an initial patch. Fixes: 3cfd59f81e0f3 ("KVM: arm64: GICv3: Handle LR overflow when EOImode==0") Fixes: 281c6c06e2a7b ("KVM: arm64: GICv2: Handle LR overflow when EOImode==0") Reported-by: Valentine Burley Tested-by: Valentine Burley Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20260307115955.369455-1-valentine.burley@collabora.com Link: https://patch.msgid.link/20260307191151.3781182-1-maz@kernel.org Cc: stable@vger.kernel.org

Merge tag 'kvmarm-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD

2025-12-02T17:36:26+00:00

KVM/arm64 updates for 6.19 - Support for userspace handling of synchronous external aborts (SEAs), allowing the VMM to potentially handle the abort in a non-fatal manner. - Large rework of the VGIC's list register handling with the goal of supporting more active/pending IRQs than available list registers in hardware. In addition, the VGIC now supports EOImode==1 style deactivations for IRQs which may occur on a separate vCPU than the one that acked the IRQ. - Support for FEAT_XNX (user / privileged execute permissions) and FEAT_HAF (hardware update to the Access Flag) in the software page table walkers and shadow MMU. - Allow page table destruction to reschedule, fixing long need_resched latencies observed when destroying a large VM. - Minor fixes to KVM and selftests