On Sun, May 12, 2013 at 6:08 PM, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > On Sun, May 12, 2013 at 06:00:38PM +0530, Kashyap Chamarthy wrote: >> >> >> >> I tried to reproduce such a problem, and I found L2 (Linux) hangs in >> >> SeaBIOS, after line "iPXE (http://ipxe.org) ...". It happens with or >> >> w/o VMCS shadowing (and even without my virtual EPT patches). I didn't >> >> realize this problem until I updated the L1 kernel to the latest (e.g. >> >> 3.9.0) from 3.7.0. L0 uses the kvm.git, next branch. It's possible >> >> that the L1 kernel exposed a bug with the nested virtualization, as we >> >> saw such cases before. >> >> >> > This is probably fixed by 8d76c49e9ffeee839bc0b7a3278a23f99101263e. Try >> > it please. >> >> I don't see the above SeaBIOS hang, however I'm able to consistently >> reproduce this stack trace when booting L1 guest: >> > You mean L2 here? Yes. (Sorry about that.) > > L2 guest cannot find root file system. Unlikely related to KVM. Yeah, fair enough. >> >> Howver, L1 boots just fine. >> >> When I try to boot L2, it throws this different stack trace. > Who is "it"? The stack trace bellow is from L0 judging by hardware name. > Again not KVM related. Again, sorry :(. I was just about to reply that this was physical host. I'm testing by disabling VMCS Shadowing per Jan Kiszka's suggestion, and retrying. But I doubt that's the reason my L2 is seg-faulting. If it still fails, I'll try to create a new L2 to see I can reproduce more consistently. Thanks for your response. /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
