https://bugzilla.kernel.org/show_bug.cgi?id=213781 --- Comment #5 from mlevitsk@xxxxxxxxxx --- On Wed, 2022-06-22 at 12:49 +0000, bugzilla-daemon@xxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=213781 > > Like Xu (like.xu.linux@xxxxxxxxx) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Kernel Version|5.14.0-rc1+ |5.19.0-rc1+ > > --- Comment #4 from Like Xu (like.xu.linux@xxxxxxxxx) --- > The issue still exits on the AMD after we revert the commit in 31c25585695a. > > Just confirmed that it's caused by non-atomic accesses to memslot: > - __do_insn_fetch_bytes() from the prot32 code page #NPF; > - kvm_vm_ioctl_set_memory_region() from user space; > > Considering the expected result [selftests::test_zero_memory_regions on > x86_64] > is that the guest will trigger an internal KVM error due to the initial code > fetch encountering a non-existent memslot and resulting in an emulation > failure. > > More similar cases will gradually emerge. I'm not sure if KVM has > documentation > pointing out this restriction on memslot updates (fix one application QEMU > may > be one-sided), or any need to add something unwise like check > gfn_to_memslot(kvm, gpa_to_gfn(cr2_or_gpa)) in the x86_emulate_instruction(). > > Any other suggestions ? > Yep, agree. This has to be fixed on qemu and kvm level (kvm needs new API to upload atomaically a set of memslot changes (easy part), and the qemu needs code to batch the memslot updates when it does SMM related memslot updates. Best regards, Maxim Levitsky -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
