Re: [libvirt] [PATCH] qemu: Do not fail virConnectCompareCPU if host CPU is not known
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.