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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
