Re: [nVMX] With 3.20.0-0.rc0.git5.1 on L0, booting L2 guest results in L1 *rebooting*

[Kashyap Chamarthy <kchamart@redhat.com>]

On Mon, Feb 23, 2015 at 05:14:37PM +0100, Kashyap Chamarthy wrote:
> On Mon, Feb 23, 2015 at 02:56:11PM +0100, Radim Krčmář wrote:
> > 2015-02-22 16:46+0100, Kashyap Chamarthy:
> > > Radim,
> > > 
> > > I just tested with your patch[1] in this thread. I built a Fedora
> > > Kernel[2] with it, and installed (and booted into) it on both L0 and L1. 
> > > 
> > > Result: I don't have good news, I'm afraid: L1 *still* reboots when an
> > >         L2 guest is booted. And, L0 throws the stack trace that was
> > >         previously noted on this thread:
> > 
> > Thanks, I'm puzzled though ... isn't it possible that a wrong kernel
> > sneaked into grub?
> 
> Hmm, unlikely - I just double-confirmed that I'm running the same
> patched Kernel (3.20.0-0.rc0.git9.1.fc23.x86_64) on both L0 and L1.

[Correcting myself here.]

Unfortunately, I was double-wrong and your guess is right -- I seemed to
have made _two_ Kernel builds (one doesn't contain your patch, and the
other) and now not sure _which_ one I used as I didn't add a custom tag.
To confuse more, I pointed the URL to wrong build (without your fix)
previously in this thread - so likely I must have used that in my last
test.

The correct build is here:

    http://koji.fedoraproject.org/koji/taskinfo?taskID=9006612

And, the build log does confirm the 'nvmx-fix.patch' that was applied

    https://kojipkgs.fedoraproject.org//work/tasks/6612/9006612/build.log

The contents of the patch, I just generated a patch with `diff -u orig
new > nvmx-fix.patch` forgetting that the Fedora Kernel handles git
formatted patches just fine.

$ cat nvmx-fix.patch 
--- vmx.c.orig  2015-02-20 19:09:49.850841320 +0100
+++ vmx.c   2015-02-20 19:11:12.153491715 +0100
@@ -2038,6 +2038,9 @@
 {
    struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
 
+    if (to_vmx(vcpu)->nested.nested_run_pending)
+        return 0;
+
    if (!(vmcs12->exception_bitmap & (1u << nr)))
        return 0;

So, my conclusion was wrong and need to report back with the _proper_
Kernel build.

-- 
/kashyap