kernel/git/next/linux-next.git/Documentation/virt/kvm/devices, branch master

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

2026-08-24T16:42:07+00:00

KVM/arm64 changes for 7.3 - Add support for 'slot' based PMU events, paired with new UAPI that compels the user to select a specific PMU implementation - Lazy save/restore of vCPU state for pKVM, along with various fixes and cleanups to the management of vCPU state between the untrusted host and pKVM hypervisor - Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1 is present, guaranteeing that EL2-specific register bits are stateful in the EL1 counterpart - Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope of those instructions remains 'in host' (i.e. L1 kernel/userspace) - Pile of fixes for the management of the VNCR pseudo-TLB, such as under-invalidations and races with concurrent TLBIs on other vCPUs - Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a runtime-patched constant, allowing the same data to be shared with pKVM prior to dropping host privileges - Considerable pile of LLM-assisted fixes around the shop but mostly in the VGIC, our in-kernel generator of bugs (and sometimes interrupts)

KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_STRICT vCPU feature

2026-07-31T06:35:24+00:00

Introduce a new vCPU feature KVM_ARM_VCPU_PMU_V3_STRICT. When set, KVM does not create a default PMU when initializing the vCPU, and userspace must select one explicitly via KVM_ARM_VCPU_PMU_V3_SET_PMU before the first KVM_RUN. The flag forces the VMM to be aware of the PMU implementation of the guest to be created, so that certain information about the PMU becomes deterministic (if on a heterogeneous system) and becomes safe to be exposed to the guest. It can be used as an umbrella flag to gate future PMUv3 UAPI changes. When no default PMU is created, kvm->arch.arm_pmu stays NULL until SET_PMU runs, so kvm_arm_pmu_v3_init() now refuses to run if kvm->arch.arm_pmu is NULL. Signed-off-by: Congkai Tan Reviewed-by: Geoff Blake Reviewed-by: Haris Okanovic Reviewed-by: Stanislav Spassov Co-developed-by: Oliver Upton Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20260722202702.4165917-5-congkai@amazon.com Signed-off-by: Oliver Upton

KVM: s390: Fall back to short-term pinning in MAP ioctl

2026-07-27T07:23:53+00:00

FOLL_LONGTERM pinning fails for some memory types, such as file-backed guest memory. As a result, kvm_s390_adapter_map() returns -EINVAL and irqfd adapter registration fails even though interrupt delivery could still work via the existing non-atomic path. When FOLL_LONGTERM pinning fails, verify that the page is accessible using a short-term pin instead. If the short-term pin succeeds, unpin the page and add a map entry with pinned=false to preserve MAP/UNMAP symmetry. The non-atomic irqfd path already performs short-term pinning for interrupt delivery, so this restores the previous behavior for memory that cannot be pinned long-term. get_map_info() is updated to return NULL for unpinned entries so that the atomic irqfd fast path falls back to the non-atomic path. kvm_s390_adapter_unmap() and kvm_s390_unmap_all_adapters() skip dirty marking and unpin for unpinned entries. Update Documentation/virt/kvm/devices/s390_flic.rst to reflect the new MAP/UNMAP behavior. Fixes: c9a568838086 ("KVM: s390: Add map/unmap ioctl and clean mappings post-guest") Signed-off-by: Jaehoon Kim Reviewed-by: Douglas Freimuth Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger

Documentation: KVM: Clarify that PMU_V3_IRQ IntID requirements for GICv5

2026-05-23T14:07:41+00:00

When running a GICv5-based guest, the PMU must use PPI 23. This, however, must be communicated via the KVM_ARM_VCPU_PMU_V3_CTRL->KVM_ARM_VCPU_PMU_V3_IRQ ioctl as a full GICv5-style Interrupt ID. That is, 0x20000017. Optionally, the whole ioctl can be skipped for GICv5. This was previously not clearly documented, so bump the documentation accordingly. Fixes: 7c31c06e2d2d ("KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Signed-off-by: Sascha Bischoff Link: https://lore.kernel.org/r/20260520091949.542365-17-maz@kernel.org Signed-off-by: Marc Zyngier

Documentation: KVM: Fix typos in VGICv5 documentation

2026-05-23T14:07:41+00:00

Fix two typos in the VGICv5 documentation. Fixes: d51c978b7d3e ("KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI") Fixes: eb3c4d2c9a4d ("Documentation: KVM: Introduce documentation for VGICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Signed-off-by: Sascha Bischoff Link: https://lore.kernel.org/r/20260520091949.542365-16-maz@kernel.org Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI

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

GICv5 systems will likely not support the full set of PPIs. The presence of any virtual PPI is tied to the presence of the physical PPI. Therefore, the available PPIs will be limited by the physical host. Userspace cannot drive any PPIs that are not implemented. Moreover, it is not desirable to expose all PPIs to the guest in the first place, even if they are supported in hardware. Some devices, such as the arch timer, are implemented in KVM, and hence those PPIs shouldn't be driven by userspace, either. Provided a new UAPI: KVM_DEV_ARM_VGIC_GRP_CTRL => KVM_DEV_ARM_VGIC_USERPSPACE_PPIs This allows userspace to query which PPIs it is able to drive via KVM_IRQ_LINE. Additionally, introduce a check in kvm_vm_ioctl_irq_line() to reject any PPIs not in the userspace mask. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-40-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

Documentation: KVM: Introduce documentation for VGICv5

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

Now that it is possible to create a VGICv5 device, provide initial documentation for it. At this stage, there is little to document. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-39-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5

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

Make it mandatory to use the architected PPI when running a GICv5 guest. Attempts to set anything other than the architected PPI (23) are rejected. Additionally, KVM_ARM_VCPU_PMU_V3_INIT is relaxed to no longer require KVM_ARM_VCPU_PMU_V3_IRQ to be called for GICv5-based guests. In this case, the architectued PPI is automatically used. Documentation is bumped accordingly. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Reviewed-by: Joey Gouly Link: https://patch.msgid.link/20260319154937.3619520-33-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

Documentation: KVM: Update GICv3 docs for GICv5 hosts

2025-10-13T13:40:58+00:00

GICv5 hosts optionally include FEAT_GCIE_LEGACY, which allows them to execute GICv3-based VMs on GICv5 hardware. Update the GICv3 documentation to reflect this now that GICv3 guests are supports on compatible GICv5 hosts. Signed-off-by: Sascha Bischoff Signed-off-by: Marc Zyngier

Documentation: KVM: Use unordered list for pre-init VGIC registers

2025-07-29T17:43:50+00:00

The intent was to create a single column table, however the markup used was actually for a header which led to docs build failures: Sphinx parallel build error: docutils.utils.SystemMessage: Documentation/virt/kvm/devices/arm-vgic-v3.rst:128: (SEVERE/4) Unexpected section title or transition. Fix the issue by converting the attempted table to an unordered list. Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/linux-next/20250729142217.0d4e64cd@canb.auug.org.au/ Signed-off-by: Oliver Upton Message-ID: <20250729152242.3232229-1-oliver.upton@linux.dev> Signed-off-by: Paolo Bonzini