From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kashyap Chamarthy <kashyapc@fedoraproject.org>
Subject: Re: [nVMX] With 3.20.0-0.rc0.git5.1 on L0, booting L2 guest results
 in L1 *rebooting*
Date: Mon, 23 Feb 2015 17:14:37 +0100
Message-ID: <20150223161437.GI30296@tesla.redhat.com>
References: <54E4C0FD.4090906@redhat.com>
 <20150219120719.GJ11686@tesla.redhat.com>
 <20150219150159.GA19057@potion.brq.redhat.com>
 <20150219160221.GB19057@potion.brq.redhat.com>
 <20150219211011.GE28728@tesla.redhat.com>
 <20150219222832.GA22611@tesla.redhat.com>
 <20150220161415.GA22152@potion.brq.redhat.com>
 <20150220194509.GD30563@tesla.home>
 <20150222154622.GA30296@tesla.redhat.com>
 <20150223135611.GB2102@potion.brq.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Kashyap Chamarthy <kchamart@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, kvm@vger.kernel.org,
	dgilbert@redhat.com
To: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:53909 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752543AbbBWQOp (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 23 Feb 2015 11:14:45 -0500
Content-Disposition: inline
In-Reply-To: <20150223135611.GB2102@potion.brq.redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Mon, Feb 23, 2015 at 02:56:11PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99 w=
rote:
> 2015-02-22 16:46+0100, Kashyap Chamarthy:
> > Radim,
> >=20
> > 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 an=
d L1.=20
> >=20
> > 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:
>=20
> 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.
=20
> > . . .
> > [<   57.747345>] ------------[ cut here ]------------
> > [<    0.004638>] WARNING: CPU: 5 PID: 50206 at arch/x86/kvm/vmx.c:8=
962 nested_vmx_vmexit+0x7ee/0x880 [kvm_intel]()
> > [<    0.060404>] CPU: 5 PID: 50206 Comm: qemu-system-x86 Not tainte=
d 3.18.7-200.fc21.x86_64 #1
>=20
> This looks like a new backtrace, but the kernel is not [2].

Err, looks like I pasted the wrong one, but here it is again. I just
tested with the patched Kernel (that I linked below) on both L0 and L1,
the same behavior (L1 reboot on L2 boot) manifests:

=2E . .
[<    0.058440>] CPU: 8 PID: 1828 Comm: qemu-system-x86 Not tainted 3.2=
0.0-0.rc0.git9.1.fc23.x86_64 #1
[<    0.008856>] Hardware name: Dell Inc. PowerEdge R910/0P658H, BIOS 2=
=2E8.2 10/25/2012
[<    0.007475>]  0000000000000000 0000000097b7f39b ffff883f5acc3bf8 ff=
ffffff818773cd
[<    0.007477>]  0000000000000000 0000000000000000 ffff883f5acc3c38 ff=
ffffff810ab3ba
[<    0.007495>]  ffff883f5acc3c68 ffff887f62678000 0000000000000000 00=
00000000000000
[<    0.007489>] Call Trace:
[<    0.002455>]  [<ffffffff818773cd>] dump_stack+0x4c/0x65
[<    0.005139>]  [<ffffffff810ab3ba>] warn_slowpath_common+0x8a/0xc0
[<    0.006001>]  [<ffffffff810ab4ea>] warn_slowpath_null+0x1a/0x20
[<    0.005831>]  [<ffffffffa220cf8e>] nested_vmx_vmexit+0xbde/0xd30 [k=
vm_intel]
[<    0.006957>]  [<ffffffffa220fda3>] ? vmx_handle_exit+0x213/0xd80 [k=
vm_intel]
[<    0.006956>]  [<ffffffffa220d3fa>] vmx_queue_exception+0x10a/0x150 =
[kvm_intel]
[<    0.007160>]  [<ffffffffa03c8cdb>] kvm_arch_vcpu_ioctl_run+0x107b/0=
x1b60 [kvm]
[<    0.007138>]  [<ffffffffa03c833a>] ? kvm_arch_vcpu_ioctl_run+0x6da/=
0x1b60 [kvm]
[<    0.007219>]  [<ffffffff8110725d>] ? trace_hardirqs_on+0xd/0x10
[<    0.005837>]  [<ffffffffa03b0666>] ? vcpu_load+0x26/0x70 [kvm]
[<    0.005745>]  [<ffffffff8110385f>] ? lock_release_holdtime.part.29+=
0xf/0x200
[<    0.006966>]  [<ffffffffa03c3a68>] ? kvm_arch_vcpu_load+0x58/0x210 =
[kvm]
[<    0.006618>]  [<ffffffffa03b0a73>] kvm_vcpu_ioctl+0x383/0x7e0 [kvm]
[<    0.006175>]  [<ffffffff81027b9d>] ? native_sched_clock+0x2d/0xa0
[<    0.006000>]  [<ffffffff810d5c56>] ? creds_are_invalid.part.1+0x16/=
0x50
[<    0.006518>]  [<ffffffff810d5cb1>] ? creds_are_invalid+0x21/0x30
[<    0.005918>]  [<ffffffff813a77fa>] ? inode_has_perm.isra.48+0x2a/0x=
a0
[<    0.006350>]  [<ffffffff8128c9a8>] do_vfs_ioctl+0x2e8/0x530
[<    0.005514>]  [<ffffffff8128cc71>] SyS_ioctl+0x81/0xa0
[<    0.005051>]  [<ffffffff81880969>] system_call_fastpath+0x12/0x17
[<    0.005999>] ---[ end trace 3e4dca7180cdddab ]---
[<    5.529564>] kvm [1766]: vcpu0 unhandled rdmsr: 0x1c9
[<    0.005026>] kvm [1766]: vcpu0 unhandled rdmsr: 0x1a6
[<    0.004998>] kvm [1766]: vcpu0 unhandled rdmsr: 0x3f6
=2E . .
=20
> > [  +0.006055]  [<ffffffff810992ea>] warn_slowpath_null+0x1a/0x20
> > [  +0.005889]  [<ffffffffa02f00ee>] nested_vmx_vmexit+0x7ee/0x880 [=
kvm_intel]
> > [  +0.007014]  [<ffffffffa02f05af>] ? vmx_handle_exit+0x1bf/0xaa0 [=
kvm_intel]
> > [  +0.007015]  [<ffffffffa02f039c>] vmx_queue_exception+0xfc/0x150 =
[kvm_intel]
> > [  +0.007130]  [<ffffffffa028cdfd>] kvm_arch_vcpu_ioctl_run+0xd9d/0=
x1290 [kvm]
>=20
> (There is only one execution path and unless there is a race, it woul=
d
>  be prevented by [1].)
>=20
> > [  +0.007111]  [<ffffffffa0288528>] ? kvm_arch_vcpu_load+0x58/0x220=
 [kvm]
> > [  +0.006670]  [<ffffffffa0274cbc>] kvm_vcpu_ioctl+0x32c/0x5c0 [kvm=
]
> [...]
> >   [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/13293=
7
> >   [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=3D9004708

--=20
/kashyap