On Thu, Oct 12, 2017 at 17:21:53 -0400, John Ferlan wrote:
On 10/04/2017 10:58 AM, Jiri Denemark wrote:
When testing cpuDecode for computing guest CPU definition from CPUID data (the CPU definition reported by domain capabilities), we need to use CPU models (and their usability blockers) from QEMU if they are available to cpuDecode in the same way it is actually used in the qemu driver.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> --- tests/cputest.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 75 insertions(+), 6 deletions(-)
diff --git a/tests/cputest.c b/tests/cputest.c index b72c17a168..18618ad309 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -515,6 +515,37 @@ cpuTestMakeQEMUCaps(const struct data *data) qemuCaps = NULL; goto cleanup; } + + +static virDomainCapsCPUModelsPtr +cpuTestGetCPUModels(const struct data *data) +{ + virDomainCapsCPUModelsPtr models = NULL; + virQEMUCapsPtr qemuCaps; + + if (data->flags != JSON_MODELS) + return NULL; + + if (!(qemuCaps = cpuTestMakeQEMUCaps(data))) + return NULL; + + models = virQEMUCapsGetCPUDefinitions(qemuCaps, VIR_DOMAIN_VIRT_KVM); + if (models) + virObjectRef(models);
As I learned a while back virObjectRef() works on a NULL @models - so no need for the if (models) (and the Unref already doesn't have one).
Oh right. Somehow when I was checking it, I looked at VIR_OBJECT_NOTVALID macro and completely ignored its body and looked at the body of VIR_OBJECT_USAGE_PRINT_WARNING macro instead which made me think virObjectRef prints some nasty warnings when obj == NULL. Jirka