https://bugzilla.kernel.org/show_bug.cgi?id=209155 --- Comment #11 from Wanpeng Li (wanpeng.li@xxxxxxxxxxx) --- (In reply to Sean Christopherson from comment #8) > From code inspection, I'm 99% confident the immediate bug is that > svm->next_rip is reset in svm_vcpu_run() only after calling > svm_exit_handlers_fastpath(), which will cause SVM's > skip_emulated_instruction() to write a stale RIP. I don't have AMD hardware > to confirm, but this should be reproducible on modern CPUs by loading > kvm_amd with nrips=0. > > That issue is easy enough to resolve, e.g. simply hoist "svm->next_rip = 0;" > up above the fastpath handling. But, there are additional complications > with advancing rip in the fastpath as svm_complete_interrupts() consumes > rip, e.g. for NMI unmasking logic and event reinjection. Odds are that NMI > unmasking will never "fail" as it would require the new rip to match the > last IRET rip, which would be very bizarre. Similarly, event reinjection > should also be a non-issue in practice as the WRMSR fastpath shouldn't be > reachable if KVM was injecting an event. > > All the being said, IMO, the safest play would be to first yank out the call > to handle_fastpath_set_msr_irqoff() in svm_exit_handlers_fastpath() to > ensure a clean base and to provide a safe backport patch, then move > svm_complete_interrupts() into svm_vcpu_run(), and finally move the call to > svm_exit_handlers_fastpath() down a ways and reenable > handle_fastpath_set_msr_irqoff(). Aside from resolving weirdness with rip > and fastpath, it would also align VMX and SVM with respect to completing > interrupts. Hi Sean, thanks for your analyses, I will send out patches to fix it. :) -- You are receiving this mail because: You are watching the assignee of the bug.
