Hi Radovan, Krystian, Here is what I tracked down so far and the conclusions:
1. Upstream fix and lore thread: In 6.8, `kvm_tdp_mmu_unmap_gfn_range()` only zaps valid roots synchronously. Roots marked invalid during memslot updates or huge page collapses are left for deferred zapping. When QEMU calls `madvise(MADV_DONTNEED)`, host MM finishes `zap_page_range_single()` and returns while those deferred roots still have active SPTEs. The guest vCPU continues to write to backing pages that the host kernel already freed and reallocated to other subsystems (which causes the delayed memory corruption in `dequeue_entity` and `kvm_replace_memslot`). Upstream reworked this in 6.9 and 6.10: - Thread on lore: "KVM: x86/mmu: Zap all roots when unmapping gfn range in TDP MMU" / "TDP MMU root and iterator cleanups" (Sean Christopherson, Paolo Bonzini). - Key commit: "KVM: x86/mmu: Ensure all invalid roots are zapped under mmu_lock" (along with traversing `KVM_ALL_ROOTS` in `kvm_tdp_mmu_unmap_gfn_range`). 2. Why Intel runs stable while AMD crashes: It comes down to NUMA topology, IPI latency, and VM density: - 4 NUMA nodes: HP DL385p Gen8 with Opteron 6386 SE has 2 dies per socket, creating 4 NUMA nodes over HyperTransport. Inter-node IPI delivery latency (`smp_call_function_many_cond` for TLB flush) is noticeably higher than on a 2-socket Intel QPI bus. - AutoNUMA churn: Running 14-20 VMs on a 4-node box means AutoNUMA (`numa_balancing=1`) is actively scanning pages with PROT_NONE and triggering `migrate_swap` across nodes. This continuous madvise/unmap churn keeps the race window open much longer compared to 5-6 idle VMs on Intel. - TLB invalidation: Intel Nehalem/Westmere uses hardware broadcast invalidation (INVEPT). AMD SVM relies on software IPIs from KVM to set `VMCB_TLB_FLUSH` for each vCPU. If that IPI is delayed across 4 NUMA nodes, the vCPU has a larger window to write to stale PTEs. Krystian: if you want to evaluate a backport for 6.8, that 6.9 TDP MMU invalid root unmap series is where to start. But honestly, I wouldn't do it. Pulling that whole MMU lifecycle rework into an LTS GA kernel carries too much regression risk for other x86 setups, especially when noble HWE 7.0 is already available, tested, and running cleanly in Radovan's production. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2163642 Title: Kernel panic "Attempted to kill the idle task" on AMD Opteron multi- node NUMA under KVM (6.8.0-137) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163642/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
