kernel.git/Documentation/virt/kvm/api.rst, branch linux-6.15.y

Documentation: kvm: remove KVM_CAP_MIPS_TE

2025-04-04T10:32:17Z

Trap and emulate virtualization is not available anymore for MIPS. Signed-off-by: Paolo Bonzini

Documentation: kvm: organize capabilities in the right section

2025-04-04T10:32:17Z

Categorize the capabilities correctly. Section 6 is for enabled vCPU capabilities; section 7 is for enabled VM capabilities; section 8 is for informational ones. Signed-off-by: Paolo Bonzini

Documentation: kvm: fix some definition lists

2025-04-04T10:32:17Z

Ensure that they have a ":" in front of the defined item. Signed-off-by: Paolo Bonzini

Documentation: kvm: drop "Capability" heading from capabilities

2025-04-04T10:32:17Z

It is redundant, and sometimes wrong. Signed-off-by: Paolo Bonzini

Documentation: kvm: give correct name for KVM_CAP_SPAPR_MULTITCE

2025-04-04T10:32:17Z

The capability is incorrectly called KVM_CAP_PPC_MULTITCE in the documentation. Signed-off-by: Paolo Bonzini

Documentation: KVM: KVM_GET_SUPPORTED_CPUID now exposes TSC_DEADLINE

2025-04-04T10:24:05Z

TSC_DEADLINE is now advertised unconditionally by KVM_GET_SUPPORTED_CPUID, since commit 9be4ec35d668 ("KVM: x86: Advertise TSC_DEADLINE_TIMER in KVM_GET_SUPPORTED_CPUID", 2024-12-18). Adjust the documentation to reflect the new behavior. Signed-off-by: Paolo Bonzini Reviewed-by: Sean Christopherson Message-ID: <20250331150550.510320-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini

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

2025-03-20T16:54:12Z

KVM/arm64 updates for 6.15 - Nested virtualization support for VGICv3, giving the nested hypervisor control of the VGIC hardware when running an L2 VM - Removal of 'late' nested virtualization feature register masking, making the supported feature set directly visible to userspace - Support for emulating FEAT_PMUv3 on Apple silicon, taking advantage of an IMPLEMENTATION DEFINED trap that covers all PMUv3 registers - Paravirtual interface for discovering the set of CPU implementations where a VM may run, addressing a longstanding issue of guest CPU errata awareness in big-little systems and cross-implementation VM migration - Userspace control of the registers responsible for identifying a particular CPU implementation (MIDR_EL1, REVIDR_EL1, AIDR_EL1), allowing VMs to be migrated cross-implementation - pKVM updates, including support for tracking stage-2 page table allocations in the protected hypervisor in the 'SecPageTable' stat - Fixes to vPMU, ensuring that userspace updates to the vPMU after KVM_RUN are reflected into the backing perf events

KVM: arm64: Fix documentation for KVM_CAP_ARM_WRITABLE_IMP_ID_REGS

2025-03-06T00:56:58Z

The capability actually fails with EINVAL if vCPUs have already been created. Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20250305230825.484091-4-oliver.upton@linux.dev Signed-off-by: Oliver Upton

KVM: arm64: Allow userspace to change the implementation ID registers

2025-02-26T09:32:16Z

KVM's treatment of the ID registers that describe the implementation (MIDR, REVIDR, and AIDR) is interesting, to say the least. On the userspace-facing end of it, KVM presents the values of the boot CPU on all vCPUs and treats them as invariant. On the guest side of things KVM presents the hardware values of the local CPU, which can change during CPU migration in a big-little system. While one may call this fragile, there is at least some degree of predictability around it. For example, if a VMM wanted to present big-little to a guest, it could affine vCPUs accordingly to the correct clusters. All of this makes a giant mess out of adding support for making these implementation ID registers writable. Avoid breaking the rather subtle ABI around the old way of doing things by requiring opt-in from userspace to make the registers writable. When the cap is enabled, allow userspace to set MIDR, REVIDR, and AIDR to any non-reserved value and present those values consistently across all vCPUs. Signed-off-by: Sebastian Ott [oliver: changelog, capability] Link: https://lore.kernel.org/r/20250225005401.679536-5-oliver.upton@linux.dev Signed-off-by: Oliver Upton

KVM: x86/xen: Restrict hypercall MSR to unofficial synthetic range

2025-02-24T16:59:55Z

Reject userspace attempts to set the Xen hypercall page MSR to an index outside of the "standard" virtualization range [0x40000000, 0x4fffffff], as KVM is not equipped to handle collisions with real MSRs, e.g. KVM doesn't update MSR interception, conflicts with VMCS/VMCB fields, special case writes in KVM, etc. While the MSR index isn't strictly ABI, i.e. can theoretically float to any value, in practice no known VMM sets the MSR index to anything other than 0x40000000 or 0x40000200. Cc: Joao Martins Reviewed-by: David Woodhouse Reviewed-by: Paul Durrant Link: https://lore.kernel.org/r/20250215011437.1203084-2-seanjc@google.com Signed-off-by: Sean Christopherson