On 10/20/2012 01:28 PM, Cole Robinson wrote: > Since the option doesn't exist. Fixes booting with > cpu mode='host-model' and qemu 1.2.0 > --- > src/qemu/qemu_capabilities.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c > index c9a4ab7..d691d51 100644 > --- a/src/qemu/qemu_capabilities.c > +++ b/src/qemu/qemu_capabilities.c > @@ -2162,7 +2162,6 @@ qemuCapsInitQMPBasic(qemuCapsPtr caps) > qemuCapsSet(caps, QEMU_CAPS_NODEFCONFIG); > qemuCapsSet(caps, QEMU_CAPS_BOOT_MENU); > qemuCapsSet(caps, QEMU_CAPS_FSDEV); > - qemuCapsSet(caps, QEMU_CAPS_NESTING); This passed 'make check', so I'm half-inclined to give ACK. But what hardware were you testing on? Was it one that allows nested virt? None of my ready-access machines allow nested virt, so I'm having a hard time reproducing the scenario, and I wonder if this is a case where older qemu was conditionally exposing the -help output based on what hardware it was running on, and where your patch now causes a regression on hardware that allows nesting. If so, then we still need some way to set the bit when appropriate - did qemu give us a counterpart QMP query-* command that we can use to determine when nested virt is supported by qemu, if we can't blindly assume it is always supported in 1.2.0+? -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list