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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list