[libvirt] [PATCH v5 25/36] qemu_capabilities: Introduce virQEMuCapsMigratablePropsDiff

[Jiri Denemark]

On Sun, Dec 02, 2018 at 23:10:19 -0600, Chris Venteicher wrote:
> Create an augmented CPUModelInfo identifying which props are/aren't
> migratable based on a diff between migratable and non-migratable
> inputs.
> 
> This patch pulls existing logic out of virQEMUCapsProbeQMPHostCPU
> and wraps the existing logic in a standalone function hopefully
> simplifying both functions and making the inputs and outputs clearer.
> 
> The patch also sets cpuData->info = NULL to make sure bad data does not
> remain in failure cases.
> 
> Q) Can the right people quickly determine if they should review this?

This does not belong to a commit message. If you have any comments or
questions, put them after the "---" line.

> 
> Signed-off-by: Chris Venteicher <cventeic at redhat.com>
> ---
>  src/qemu/qemu_capabilities.c | 131 ++++++++++++++++++++++++-----------
>  1 file changed, 92 insertions(+), 39 deletions(-)
> 
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index cd685298e6..bd75f82e70 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -2378,14 +2378,91 @@ virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr qemuCaps,
>  }
>  
>  
> +/* virQEMUCapsMigratablePropsDiff

The name is quite misleading. The function does not produce a diff, it
just uses two different views on CPU props to set migratable flags for
each prop.

> + * @migratable: input where all migratable props have value true
> + * and non-migratable and unsupported props have value false
> + *
> + * @nonMigratable: input where all migratable & non-migratable props
> + * have value true and unsupported props have value false
> + *
> + * @augmented: output including all props listed in @migratable but
> + * both migratable & non-migratable props have value true,
> + * unsupported props have value false,
> + * and prop->migratable is set to VIR_TRISTATE_BOOL_{YES/NO}
> + * for each supported prop

I think it would make more sense to just return the augmented ModelInfo.
The function will never set @augmented = NULL on success and thus we can
return NULL on error. That way you could get rid of the strange tmp
variable, which is quite a bit more than just a simple temporary
variable.

> + *
> + * Differences in expanded CPUModelInfo inputs @migratable and @nonMigratable are
> + * used to create output @augmented where individual props have prop->migratable
> + * set to indicate if prop is or isn't migratable.
> + */
> +static int
> +virQEMUCapsMigratablePropsDiff(qemuMonitorCPUModelInfoPtr migratable,
> +                               qemuMonitorCPUModelInfoPtr nonMigratable,
> +                               qemuMonitorCPUModelInfoPtr *augmented)
> +{
> +    int ret = -1;
> +    qemuMonitorCPUModelInfoPtr tmp;
> +    qemuMonitorCPUPropertyPtr prop;
> +    qemuMonitorCPUPropertyPtr mProp;
> +    qemuMonitorCPUPropertyPtr nmProp;
> +    virHashTablePtr hash = NULL;
> +    size_t i;
> +
> +    *augmented = NULL;
> +
> +    if (!(tmp = qemuMonitorCPUModelInfoCopy(migratable)))
> +        goto cleanup;
> +
> +    if (!nonMigratable)
> +        goto done;
> +
> +    if (!(hash = virHashCreate(0, NULL)))
> +        goto cleanup;
> +
> +    for (i = 0; i < tmp->nprops; i++) {
> +        prop = tmp->props + i;
> +
> +        if (virHashAddEntry(hash, prop->name, prop) < 0)
> +            goto cleanup;
> +    }
> +
> +    for (i = 0; i < nonMigratable->nprops; i++) {
> +        nmProp = nonMigratable->props + i;

"nmProp" and "mProp" look very similar, it took me some time to realize
they are different.

> +
> +        if (!(mProp = virHashLookup(hash, nmProp->name)) ||
> +            mProp->type != QEMU_MONITOR_CPU_PROPERTY_BOOLEAN ||
> +            mProp->type != nmProp->type)
> +            continue;  /* In non-migratable list but not in migratable list */
> +
> +        if (mProp->value.boolean) {
> +            mProp->migratable = VIR_TRISTATE_BOOL_YES;
> +        } else if (nmProp->value.boolean) {
> +            mProp->value.boolean = true;
> +            mProp->migratable = VIR_TRISTATE_BOOL_NO;
> +        }
> +    }
> +
> +    tmp->migratability = true;
> +
> + done:
> +    VIR_STEAL_PTR(*augmented, tmp);
> +    ret = 0;
> +
> + cleanup:
> +    qemuMonitorCPUModelInfoFree(tmp);
> +    virHashFree(hash);
> +    return ret;
> +}
> +
> +
>  static int
>  virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
>                             qemuMonitorPtr mon,
>                             bool tcg)
>  {
> -    qemuMonitorCPUModelInfoPtr modelInfo = NULL;
> +    qemuMonitorCPUModelInfoPtr migratable = NULL;
>      qemuMonitorCPUModelInfoPtr nonMigratable = NULL;
> -    virHashTablePtr hash = NULL;
> +    qemuMonitorCPUModelInfoPtr augmented = NULL;
>      const char *model;
>      qemuMonitorCPUModelExpansionType type;
>      virDomainVirtType virtType;
> @@ -2404,6 +2481,7 @@ virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
>      }
>  
>      cpuData = virQEMUCapsGetHostCPUData(qemuCaps, virtType);
> +    cpuData->info = NULL;

This is pretty suspicious. Either cpuData->info was already NULL and
there's no need to reset it again or we just leaked the memory
cpuData->info was pointing to.

>  
>      /* Some x86_64 features defined in cpu_map.xml use spelling which differ
>       * from the one preferred by QEMU. Static expansion would give us only the
...

Jirka