On Sun, 2020-09-20 at 18:42 +0200, Paolo Bonzini wrote: > On 20/09/20 18:16, Sean Christopherson wrote: > > > Maxim, your previous version was adding some error handling to > > > kvm_x86_ops.set_efer. I don't remember what was the issue; did you have > > > any problems propagating all the errors up to KVM_SET_SREGS (easy), > > > kvm_set_msr (harder) etc.? > > I objected to letting .set_efer() return a fault. > > So did I, and that's why we get KVM_REQ_OUT_OF_MEMORY. But it was more > of an "it's ugly and it ought not to fail" thing than something I could > pinpoint. > > It looks like we agree, but still we have to choose the lesser evil? > > Paolo > > > A relatively minor issue is > > the code in vmx_set_efer() that handles lack of EFER because technically KVM > > can emulate EFER.SCE+SYSCALL without supporting EFER in hardware. Returning > > success/'0' would avoid that particular issue. My primary concern is that I'd > > prefer not to add another case where KVM can potentially ignore a fault > > indicated by a helper, a la vmx_set_cr4(). The thing is that kvm_emulate_wrmsr injects #GP when kvm_set_msr returns any non zero value, and returns 1 which means keep on going if I understand correctly (0 is userspace exit, negative value would be a return to userspace with an error) So the question is if we have other wrmsr handlers which return negative value, and would be affected by changing kvm_emulate_wrmsr to pass through the error value. I am checking the code now. I do agree now that this is the *correct* solution to this problem. Best regards, Maxim Levitsky
