Re: [Libguestfs] Double fault panic in L2 upon v2v conversion

On 01/17/2014 03:38 PM, Richard W.M. Jones wrote: > On Fri, Jan 17, 2014 at 04:14:03PM +0200, Rom Freiman wrote: >> How do you know that the problem is with KVM/QEMU and not with libguestfs? > > The guestfsd daemon is simply running the regular 'mount' command. > The mount command causes the kernel to panic. There should be no > circumstances where running an ordinary command like that, albeit as > root, should cause the kernel to panic. Unless the kernel (or in this > case, something underneath the kernel) is broken. > > mount -o ro /dev/sdb /sysroot/ > [ 12.645305] PANIC: double fault, error_code: 0x0 > [ 12.645305] CPU: 0 PID: 141 Comm: mount Not tainted > 3.11.8-200.strato0002.fc19.strato.c3850ae03e9d.x86_64 #1 > [ 12.645305] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > [ 12.645305] task: ffff88001cc816e0 ti: ffff88001cde6000 task.ti: > ffff88001cde6000 > [ 12.645305] RIP: 0033:[<00007fa602c5b99b>] [<00007fa602c5b99b>] > 0x7fa602c5b99a > [ 12.645305] RSP: 002b:00007fff4f5884a0 EFLAGS: 00010216 > [ 12.645305] RAX: 00007fa602008ff8 RBX: 00007fa601ff0000 RCX: 00007fa601ff0000 > [ 12.645305] RDX: 00000000003b7068 RSI: 00007fff4f588560 RDI: 00007fa601ff3d18 > [ 12.645305] RBP: 00007fff4f5885d0 R08: 00007fa60200f310 R09: 0000000000000000 > [ 12.645305] R10: 0000000000000022 R11: 00007fa60200f310 R12: 00007fa60200e9b0 > [ 12.645305] R13: 0000000000000000 R14: 0000000000000000 R15: 00007fa602e6e990 > [ 12.645305] FS: 00007fa602e69880(0000) GS:ffff88001f000000(0000) > knlGS:0000000000000000 > [ 12.645305] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 12.645305] CR2: 0000000000000000 CR3: 000000001d7fb000 CR4: 00000000000006f0 > [ 12.645305] > [ 12.645305] Kernel panic - not syncing: Machine halted. > [ 12.645305] CPU: 0 PID: 141 Comm: mount Not tainted > 3.11.8-200.strato0002.fc19.strato.c3850ae03e9d.x86_64 #1 > [ 12.645305] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > [ 12.645305] ffff88001f005f58 ffff88001f005e90 ffffffff8164024b > ffffffff819e89dc > [ 12.645305] ffff88001f005f08 ffffffff8163c272 0000000000000008 > ffff88001f005f18 > [ 12.645305] ffff88001f005eb8 ffffffff8163c8e5 0000000000000046 > 00000000000000b1 > [ 12.645305] Call Trace: > [ 12.645305] <#DF> [<ffffffff8164024b>] dump_stack+0x45/0x56 > [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 > [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 > [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 > [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 > [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 > [ 12.645305] <<EOE>> Correct. I encountered this same double_fault panic a week ago: http://kashyapc.fedorapeople.org/temp/double-fault-panic-nested-kvm-envir... With these versions: $ uname -r ; rpm -q libvirt qemu-system-x86 3.11.10-301.fc20.x86_64 libvirt-1.1.3.1-2.fc20.x86_64 qemu-system-x86-1.6.1-2.fc20.x86_64 When I briefly discussed this double fault panic with Paolo Bonzini (KVM maintainer), he mentioned it is probably a host hypervisor bug. But this needs more investigation (ftrace for nested guest, x86info in L1 and L2 - if possible). Answering Rom's earlier question ("Kashyap, can you please share your experience?"): Yes, ested virtualization with KVM and Intel is not *really* the most stable, but there's on going work upstream to improve this and fix bbugs. Refer these recent bugs I filed while in a nested KVM environment: https://bugzilla.kernel.org/show_bug.cgi?id=67761 https://bugzilla.kernel.org/show_bug.cgi?id=68051 https://bugzilla.kernel.org/show_bug.cgi?id=67751 -- /kashyap