Messages in this thread | | | Date | Thu, 20 Jan 2022 15:48:19 +0800 | Subject | Re: [DROP][PATCH] KVM: x86: Fix the #GP(0) and #UD conditions for XSETBV emulation | From | Like Xu <> |
| |
On 17/1/2022 7:18 pm, Paolo Bonzini wrote: > On 1/17/22 10:44, Like Xu wrote: >>> Also, the "Fixes" tag is not really correct as the behavior was the same >>> before. Rather, it fixes commit 02d4160fbd76 ("x86: KVM: add xsetbv to the >> >> It seems the original code comes from 81dd35d42c9a ("KVM: SVM: Add xsetbv >> intercept"). >> 2acf923e38 ("KVM: VMX: Enable XSAVE/XRSTOR for guest") and 92f9895c146d. >> >>> emulator", 2019-08-22). Checking OSXSAVE is a bug in the emulator path, even >>> though it's not needed in the XSETBV vmexit case. >> >> The kvm_emulate_xsetbv() has been removed from the emulator path. >> I'm not really sure why it's not needed in the XSETBV vmexit case. More details ? > > Nevermind, I confused AMD (where #UD is generated before checking for > exceptions) with Intel where it's unconditional. > > So the bug should be there since 2acf923e38 by executing XSETBV with > CR4.XSAVE=0. If so, please include a testcase.
In the testcase "executing XSETBV with CR4.XSAVE=0",
- on the VMX, #UD delivery does not require vm-exit; - on the SVM, #UD is trapped but goes to the ud_interception() path;
There is no room to run this pointless patch. Thank you and sorry for the noise.
> > Paolo > >>> >>> Thanks, >>> >>> Paolo >>> >>>> + if ((is_protmode(vcpu) && static_call(kvm_x86_get_cpl)(vcpu) != 0) || >>>> __kvm_set_xcr(vcpu, kvm_rcx_read(vcpu), kvm_read_edx_eax(vcpu))) { >>>> kvm_inject_gp(vcpu, 0); >>>> return 1; >>> >>> >> > >
| |