Re: [pve-devel] [PATCH pve-kernel 2/2] cherry-pick fix for uefi guests hanging upon guest-initialized reboot

[Fiona Ebner <f.ebner@proxmox.com>]

Am 24.08.23 um 16:30 schrieb Stoiko Ivanov:
> 
> https://lore.kernel.org/lkml/20230608090348.414990-1-gshan@redhat.com/
> 

Note that this is actually about an older version of the patch.

> +
> +We tried a git-bisect and the first problematic commit is cd4c71835228 ("
> +KVM: arm64: Convert to the gfn-based MMU notifier callbacks"). With this,
> +clean_dcache_guest_page() is called after the memory slots are iterated
> +in kvm_mmu_notifier_change_pte(). clean_dcache_guest_page() is called
> +before the iteration on the memory slots before this commit. This change
> +literally enlarges the racy window between kvm_mmu_notifier_change_pte()
> +and memory slot removal so that we're able to reproduce the issue in a
> +practical test case. However, the issue exists since commit d5d8184d35c9
> +("KVM: ARM: Memory virtualization setup").
> +
> +Cc: stable@vger.kernel.org # v3.9+
> +Fixes: d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")

The mentioned commits and reading in the mail thread

>> Cc: stable@vger.kernel.org # v5.13+
>> Fixes: 3039bcc74498 ("KVM: Move x86's MMU notifier memslot walkers to generic code")
> 
> This Fixes isn't correct.  That change only affected x86, which doesn't have this
> bug.  And looking at commit cd4c71835228 ("KVM: arm64: Convert to the gfn-based MMU
> notifier callbacks"), arm64 did NOT skip invalid slots

unfortunately make it sound like it's not an x86 issue. But who knows? I
guess it won't hurt in either case, as it's already in upstream stable.