On Thu, Jul 12, 2012 at 01:06:08PM +0200, Jiri Denemark wrote:
When host CPU could not be properly detected, virConnectCompareCPU will just report that any CPU is incompatible with host CPU instead of failing. --- src/qemu/qemu_driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index dc04d13..6d3b8d5 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -9419,8 +9419,8 @@ qemuCPUCompare(virConnectPtr conn, qemuDriverLock(driver);
if (!driver->caps || !driver->caps->host.cpu) { - qemuReportError(VIR_ERR_OPERATION_INVALID, - "%s", _("cannot get host CPU capabilities")); + VIR_WARN("cannot get host CPU capabilities"); + ret = VIR_CPU_COMPARE_INCOMPATIBLE; } else { ret = cpuCompareXML(driver->caps->host.cpu, xmlDesc); }
Jiri, I think that I've changed my own taste about this, too. I don't know what can lead driver->caps to be NULL, but I support that many things that are unrelated to host CPU can. If this is the case, the caller of cpuCompareXML may receive a misleading VIR_CPU_COMPARE_INCOMPATIBLE. Limiting the new ret to the case of driver->caps->host.cpu == NULL would have been better. But again: is there a chance that driver->caps->host.cpu is NULL due to lack of memory during host probing? I'm still wondering why libvirt must detect a known hardware cpu on the host. In the age of nested virt, it may find more bizarre combinations, that it may be interesting to support. Dan.