On 06.12.2017 15:40, David Hildenbrand wrote: > On 06.12.2017 12:59, Wanpeng Li wrote: >> From: Wanpeng Li <wanpeng.li@xxxxxxxxxxx> >> >> *** Guest State *** >> CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 >> CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871 >> CR3 = 0x00000000fffbc000 >> RSP = 0x0000000000000000 RIP = 0x0000000000000000 >> RFLAGS=0x00000000 DR7 = 0x0000000000000400 >> ^^^^^^^^^^ >> >> The failed vmentry is triggered by the following testcase when ept=Y: >> >> #include <unistd.h> >> #include <sys/syscall.h> >> #include <string.h> >> #include <stdint.h> >> #include <linux/kvm.h> >> #include <fcntl.h> >> #include <sys/ioctl.h> >> >> long r[5]; >> int main() >> { >> r[2] = open("/dev/kvm", O_RDONLY); >> r[3] = ioctl(r[2], KVM_CREATE_VM, 0); >> r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); >> struct kvm_regs regs = { >> .rflags = 0, >> }; >> ioctl(r[4], KVM_SET_REGS, ®s); >> ioctl(r[4], KVM_RUN, 0); >> } >> >> X86 RFLAGS bit 1 is fixed set, userspace can simply clearing bit 1 >> of RFLAGS with KVM_SET_REGS ioctl which results in vmentry fails. >> This patch fixes it by oring X86_EFLAGS_FIXED during ioctl. >> >> Suggested-by: Jim Mattson <jmattson@xxxxxxxxxx> >> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> >> Cc: Radim Krčmář <rkrcmar@xxxxxxxxxx> >> Cc: Jim Mattson <jmattson@xxxxxxxxxx> >> Signed-off-by: Wanpeng Li <wanpeng.li@xxxxxxxxxxx> >> --- >> v1 -> v2: >> * Oring X86_EFLAGS_FIXED >> >> virt/kvm/kvm_main.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c >> index b55bad3..0f3f283 100644 >> --- a/virt/kvm/kvm_main.c >> +++ b/virt/kvm/kvm_main.c >> @@ -2602,6 +2602,7 @@ static long kvm_vcpu_ioctl(struct file *filp, >> r = PTR_ERR(kvm_regs); >> goto out; >> } >> + kvm_regs->rflags |= X86_EFLAGS_FIXED; Just realized that this should go into kvm_arch_vcpu_ioctl_set_regs(). >> r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs); >> kfree(kvm_regs); >> break; >> > > Not sure if failing KVM_SET_REGS would be nicer, but maybe this has > already been discussed. So this should be fine. > > Reviewed-by: David Hildenbrand <david@xxxxxxxxxx> > -- Thanks, David / dhildenb