Hi Nicolas, interesting. Seeing CPUID.07H:EBX.invpcid makes me wonder - IIRC that was a speedup feature long neglected by everyone but suddenly becoming important in the context of meltdown avoidance. Maybe that wasn't passed/emulated in the older qemu but the guest now insists or misdetects it?
This also would sort of match your statement "It worked some times ago, but not anymore." as the meltdown fixes obviously came after the release of 16.04. Let me try to recreate your initial case first with 16.04->16.04->16.04. I took a fresh deployed Xenial host and deployed a Xenial guest in lvl1 $ sudo apt install uvtool-libvirt $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily $ uvt-kvm create --memory 4096 --disk 30 --cpu 4 --password ubuntu xenial-guest-lvl1 arch=amd64 release=xenial label=daily And then in the lvl1 guest doing the same to spawn a smaller lvl2 guest. ... # note: back then (16.04) nested default libvirt network needed to manually get to work before the next command $ uvt-kvm create --password ubuntu xenial-guest-lvl2 arch=amd64 release=xenial label=daily That guest runs just fine and is happy. So it has to be part of your guest configuration in some way. $ cat /proc/cpuinfo | grep invpcid Report it is available on the Host (lvl0) but none of the guests (lvl1/lvl2). I did not see a warning like yours about CPUID.07H:EBX.invpcid (on neither of the lvls). My guests are defined the "most default" way possible leaving most of the cpu construction to the defaults of libvirt/qemu. virsh dumpxml content: lvl1 => http://paste.ubuntu.com/p/fH57d5prmS/ lvl2 => http://paste.ubuntu.com/p/vQbcgfmfVv/ I wonder if your way to setup the guests uses special CPU types that define the meltdowny features - like the -IBRS types or even adding features like those mentioned in [1]. E.g. Virt-manager would default to "Haswell-noTSX-IBRS" on my system with the virt stack of 16.04. If I use that in my guest definition (on both levels) <cpu mode='custom' match='exact'> <model fallback='allow'>Haswell-noTSX-IBRS</model> </cpu> Now I get invpcid in $ cat /proc/cpuinfo | grep invpcid in the lvl1 guest. But since this type lacks the KVM features I'm no more assuming but waiting for your reply on how guest CPU is modelled in your case. But in general in that case i could think of this being a potential trouble for (x86) nesting which is generally known as "working great until it does't" Waiting for your feedback on guest CPU definitions in your case. [1]: https://www.berrange.com/posts/2018/06/29/cpu-model-configuration- for-qemu-kvm-on-x86-hosts/ ** Changed in: qemu (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797332 Title: qemu nested virtualization is not working with Ubuntu16.04 + Intel CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1797332/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
