diff mbox

nVMX regression v3.13+, bisected

Message ID OF57791EAC.75BA2FC8-ONC1257C8C.004B2ECA-C1257C8C.004B2ED6@local (mailing list archive)
State New, archived
Headers show

Commit Message

anthoine.bourgeois@bertin.fr Feb. 27, 2014, 1:41 p.m. UTC 
-----Paolo Bonzini <paolo.bonzini@gmail.com> a écrit : -----
Il 26/02/2014 21:27, Stefan Bader ha scritto:
> On 26.02.2014 21:25, Paolo Bonzini wrote:
>> Il 26/02/2014 20:43, Stefan Bader ha scritto:
>>> Hi,
>>>
>>> I was looking at a bug report[1] about a regression on nested VMX that started
>>> with kernel v3.13 (same issue still existed with v3.14-rc4). The problem shows
>>> up when running a v3.13 kernel in L0 and then trying to launch a L2 (L1 was
>>> either a v3.2 kernel or v3.13, so seemed to have no immediate influence). L2 is
>>> trying to boot a iso image and hangs before the isolinux boot loader displays
>>> anything. A preinstalled hd image fails to boot, too.
>>>
>>> I bisected this and ended up on the following commit which, when reverted made
>>> the launch work again:
>>>
>>> Author: Anthoine Bourgeois <bourgeois@bertin.fr>
>>> Date:   Wed Nov 13 11:45:37 2013 +0100
>>>
>>>     kvm, vmx: Fix lazy FPU on nested guest
>>>
>>>     If a nested guest does a NM fault but its CR0 doesn't contain the TS
>>>     flag (because it was already cleared by the guest with L1 aid) then we
>>>     have to activate FPU ourselves in L0 and then continue to L2. If TS flag
>>>     is set then we fallback on the previous behavior, forward the fault to
>>>     L1 if it asked for.
>>>
>>>     Signed-off-by: Anthoine Bourgeois <bourgeois@bertin.fr>
>>>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>
>>> The condition to exit to L0 seems to be according to what the description says.
>>> Could it be that the handling in L0 is doing something wrong?
>>
>> Thanks, I'll look at it tomorrow or Friday.
>>
>> Paolo
>>
> Great thanks. And maybe it helps if I actually add the link to the bug report as
> I had intended... :-P

I don't have my usual test machine available, but here is a possible guess.
nested_read_cr0 is the CR0 as read by L2, but here we want to look at the
CR0 value reflecting L1's setup.  This would suggest the following untested
patch:


Hi,

I install a new test machine and I test the patch. I'll report as soon as possible.

Regards,
Anthoine
1
diff mbox

Patch

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a06f101ef64b..0d90601a2681 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6688,7 +6688,7 @@  static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu)
 	 else if (is_page_fault(intr_info))
 	 return enable_ept;
 	 else if (is_no_device(intr_info) &&
-	 !(nested_read_cr0(vmcs12) & X86_CR0_TS))
+	 !(vmcs12->guest_cr0 & X86_CR0_TS))
 	 return 0;
 	 return vmcs12->exception_bitmap &
 	 (1u << (intr_info & INTR_INFO_VECTOR_MASK));