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(a)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