On Sat, May 18, 2024 at 12:51 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 5/17/24 13:37, Liang Chen wrote: > >> > >> The attached cleaned up reproducer shows that the problem is simply that > >> EFLAGS.VM is set in 64-bit mode. To fix it, it should be enough to do > >> a nested_vmx_vmexit(vcpu, EXIT_REASON_TRIPLE_FAULT, 0, 0); just like > >> a few lines below. > >> > > Yes, that was the situation we were trying to deal with. However, I am > > not quite sure if I fully understand the suggestion, "To fix it, it > > should be enough to do a nested_vmx_vmexit(vcpu, > > EXIT_REASON_TRIPLE_FAULT, 0, 0); just like a few lines below.". From > > what I see, "(vmx->nested.nested_run_pending, vcpu->kvm) == true" in > > __vmx_handle_exit can be a result of an invalid VMCS12 from L1 that > > somehow escaped checking when trapped into L0 in nested_vmx_run. It is > > not convenient to tell whether it was a result of userspace > > register_set ops, as we are discussing, or an invalid VMCS12 supplied > > by L1. > > Right, KVM assumes that it can delegate the "Checks on Guest Segment > Registers" to the processor if a field is copied straight from VMCS12 to > VMCS02. In this case the segments are not set up for virtual-8086 mode; > interestingly the manual seems to say that EFLAGS.VM wins over "IA-32e > mode guest" is 1 for the purpose of checking guest state. AMD's manual > says that EFLAGS.VM is completely ignored in 64-bit mode instead. > > I need to look more at the sequence of VMLAUNCH/RESUME, KVM_SET_MSR and > the failed vmentry to understand exactly what the right fix is. Yep. Thanks a lot! Thanks, Liang > > Paolo > > > Additionally, nested_vmx_vmexit warns when > > 'vmx->nested.nested_run_pending is true,' saying that "trying to > > cancel vmlaunch/vmresume is a bug". >
