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. > > . . . > > [< 57.747345>] ------------[ cut here ]------------ > > [< 0.004638>] WARNING: CPU: 5 PID: 50206 at arch/x86/kvm/vmx.c:8962 nested_vmx_vmexit+0x7ee/0x880 [kvm_intel]() > > [< 0.060404>] CPU: 5 PID: 50206 Comm: qemu-system-x86 Not tainted 3.18.7-200.fc21.x86_64 #1 > > 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: . . . [< 0.058440>] CPU: 8 PID: 1828 Comm: qemu-system-x86 Not tainted 3.20.0-0.rc0.git9.1.fc23.x86_64 #1 [< 0.008856>] Hardware name: Dell Inc. PowerEdge R910/0P658H, BIOS 2.8.2 10/25/2012 [< 0.007475>] 0000000000000000 0000000097b7f39b ffff883f5acc3bf8 ffffffff818773cd [< 0.007477>] 0000000000000000 0000000000000000 ffff883f5acc3c38 ffffffff810ab3ba [< 0.007495>] ffff883f5acc3c68 ffff887f62678000 0000000000000000 0000000000000000 [< 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 [kvm_intel] [< 0.006957>] [<ffffffffa220fda3>] ? vmx_handle_exit+0x213/0xd80 [kvm_intel] [< 0.006956>] [<ffffffffa220d3fa>] vmx_queue_exception+0x10a/0x150 [kvm_intel] [< 0.007160>] [<ffffffffa03c8cdb>] kvm_arch_vcpu_ioctl_run+0x107b/0x1b60 [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/0xa0 [< 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 . . . > > [ +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/0x1290 [kvm] > > (There is only one execution path and unless there is a race, it would > be prevented by [1].) > > > [ +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/132937 > > [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=9004708 -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
