[libvirt] [PATCH v5 25/36] qemu_capabilities: Introduce virQEMuCapsMigratablePropsDiff
Jiri Denemark
jdenemar at redhat.com
Fri Jan 4 20:00:02 UTC 2019
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
More information about the libvir-list
mailing list