kernel/linux.git/arch/arm64/kvm/nested.c, branch linux-7.1.y

KVM: arm64: Reassign nested_mmus array behind mmu_lock

2026-06-05T10:48:41+00:00

kvm->arch.nested_mmus[] is walked under kvm->mmu_lock, including from the MMU notifier path (kvm_unmap_gfn_range() -> kvm_nested_s2_unmap()), which can run at any time. kvm_vcpu_init_nested() reallocates the array and frees the old buffer while holding only kvm->arch.config_lock, so such a walker can reference the freed array. Allocate the new array outside of mmu_lock, as the allocation can sleep. Under the lock, copy the existing entries, fix up the back pointers and reassign the array. Free the old buffer after dropping the lock, as kvfree() can sleep as well. Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Signed-off-by: Hyunwoo Kim Reviewed-by: Oliver Upton Link: https://patch.msgid.link/aiKIVVeIr1aAB1yp@v4bel Signed-off-by: Marc Zyngier Cc: stable@vger,kernel.org

KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor

2026-05-29T09:04:00+00:00

ZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2 (which traps) or ZCR_EL1 (which does not trap). KVM handles both in different way: - on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM's own VL limit. This has the potential to break existing SW that relies on the full LEN field to be stateful. - on ZCR_EL1 access, we do absolutely nothing. On restoring the SVE context for an L2 guest, we directly restore the guest hypervisor's view of ZCR_EL2 into the physical ZCR_EL2. If the guest's view of the register was updated using the ZCR_EL2 accessor, the value has already been sanitised (with the caveat mentioned above). But if the guest used ZCR_EL1, the raw value is written into the HW, and the L2 guest can now access VLs that it shouldn't. Fix all the above by moving the VL capping to the restore points, ensuring that: - the HW is always programmed with a capped value, irrespective of the accessor being used, - the ZCR_EL2.LEN field is always completely stateful, irrespective of the accessor being used. Additionally, move ZCR_EL2 to be a sanitised register, ensuring that only the LEN field is actually stateful. This requires some creative construction of the RES0 mask, as the sysreg generation script does not yet generate RAZ/WI fields. Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260529-kvm-arm64-fix-zcr-len-nv-v2-1-86cad51992bd@kernel.org [maz: rewrote commit message, tidy up access_zcr_el2()] Signed-off-by: Marc Zyngier

Merge branch kvm-arm64/nv-s2-debugfs into kvmarm-master/next

2026-04-08T11:22:55+00:00

* kvm-arm64/nv-s2-debugfs: : . : Expand the stage-2 ptdump infrastructure to be able to display : the content of the shadow s2 tables generated by nested virt. : : Patches courtesy of Wei-Lin Chang. : . KVM: arm64: ptdump: Initialize parser_state before pgtable walk KVM: arm64: nv: Expose shadow page tables in debugfs KVM: arm64: ptdump: Make KVM ptdump code s2 mmu aware Signed-off-by: Marc Zyngier

KVM: arm64: nv: Expose shadow page tables in debugfs

2026-03-23T10:06:50+00:00

Exposing shadow page tables in debugfs improves the debugability and testability of NV. With this patch a new directory "nested" is created for each VM created if the host is NV capable. Within the directory each valid s2 mmu will have its shadow page table exposed as a readable file with the file name formatted as 0x-0x-s2-{en,dis}abled. The creation and removal of the files happen at the points when an s2 mmu becomes valid, or the context it represents change. In the future the "nested" directory can also hold other NV related information. This is gated behind CONFIG_PTDUMP_STAGE2_DEBUGFS. Suggested-by: Marc Zyngier Reviewed-by: Sebastian Ene Signed-off-by: Wei-Lin Chang Reviewed-by: Joey Gouly Link: https://patch.msgid.link/20260317182638.1592507-3-weilin.chang@arm.com [maz: minor refactor, full 16 chars addresses] Signed-off-by: Marc Zyngier

KVM: arm64: gic-v5: Hide FEAT_GCIE from NV GICv5 guests

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

Currently, NV guests are not supported with GICv5. Therefore, make sure that FEAT_GCIE is always hidden from such guests. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260319154937.3619520-35-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier

KVM: arm64: nv: Inject a SEA if failed to read the descriptor

2026-03-05T15:46:48+00:00

Failure to read the descriptor (because it is outside of a memslot) should result in a SEA being injected in the guest. Suggested-by: Marc Zyngier Link: https://lore.kernel.org/r/86ms1m9lp3.wl-maz@kernel.org Signed-off-by: Zenghui Yu (Huawei) Link: https://patch.msgid.link/20260225173515.20490-4-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier

KVM: arm64: nv: Report addrsz fault at level 0 with a bad VTTBR.BADDR

2026-03-05T15:46:48+00:00

As per R_BFHQH, " When an Address size fault is generated, the reported fault code indicates one of the following: If the fault was generated due to the TTBR_ELx used in the translation having nonzero address bits above the OA size, then a fault at level 0. " Fix the reported Address size fault level as being 0 if the base address is wrongly programmed by L1. Fixes: 61e30b9eef7f ("KVM: arm64: nv: Implement nested Stage-2 page table walk logic") Signed-off-by: Zenghui Yu (Huawei) Link: https://patch.msgid.link/20260225173515.20490-3-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier

KVM: arm64: nv: Check S2 limits based on implemented PA size

2026-03-05T15:46:47+00:00

check_base_s2_limits() checks the validity of SL0 and inputsize against ia_size (inputsize again!) but the pseudocode from DDI0487 G.a AArch64.TranslationTableWalk() says that we should check against the implemented PA size. We would otherwise fail to walk S2 with a valid configuration. E.g., granule size = 4KB, inputsize = 40 bits, initial lookup level = 0 (no concatenation) on a system with 48 bits PA range supported is allowed by architecture. Fix it by obtaining PA size by kvm_get_pa_bits(). Note that kvm_get_pa_bits() returns the fixed limit now and should eventually reflect the per VM PARange (one day!). Given that the configured PARange should not be greater that kvm_ipa_limit, it at least fixes the problem described above. While at it, inject a level 0 translation fault to guest if check_base_s2_limits() fails, as per the pseudocode. Fixes: 61e30b9eef7f ("KVM: arm64: nv: Implement nested Stage-2 page table walk logic") Signed-off-by: Zenghui Yu (Huawei) Link: https://patch.msgid.link/20260225173515.20490-2-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier

Merge tag 'kvmarm-fixes-7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD

2026-02-28T14:33:34+00:00

KVM/arm64 fixes for 7.0, take #1 - Make sure we don't leak any S1POE state from guest to guest when the feature is supported on the HW, but not enabled on the host - Propagate the ID registers from the host into non-protected VMs managed by pKVM, ensuring that the guest sees the intended feature set - Drop double kern_hyp_va() from unpin_host_sve_state(), which could bite us if we were to change kern_hyp_va() to not being idempotent - Don't leak stage-2 mappings in protected mode - Correctly align the faulting address when dealing with single page stage-2 mappings for PAGE_SIZE > 4kB - Fix detection of virtualisation-capable GICv5 IRS, due to the maintainer being obviously fat fingered... - Remove duplication of code retrieving the ASID for the purpose of S1 PT handling - Fix slightly abusive const-ification in vgic_set_kvm_info()

KVM: arm64: Deduplicate ASID retrieval code

2026-02-25T12:19:33+00:00

We currently have three versions of the ASID retrieval code, one in the S1 walker, and two in the VNCR handling (although the last two are limited to the EL2&0 translation regime). Make this code common, and take this opportunity to also simplify the code a bit while switching over to the TTBRx_EL1_ASID macro. Reviewed-by: Joey Gouly Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260225104718.14209-1-maz@kernel.org Signed-off-by: Marc Zyngier