[libvirt] [PATCH 1/7] cpu: Introduce virCPUCopyMigratable

John Ferlan jferlan at redhat.com
Tue Apr 4 16:31:00 UTC 2017



On 03/31/2017 01:53 PM, Jiri Denemark wrote:
> This new internal API makes a copy of virCPUDef while removing all
> features which would block migration. It uses cpu_map.xml as a database
> of such features, which should only be used as a fallback when we cannot
> get the data from a hypervisor. The main goal of this API is to decouple
> this filtering from virCPUUpdate so that the hypervisor driver can
> filter the features according to the hypervisor.
> 
> Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
> ---
>  src/cpu/cpu.c            | 29 +++++++++++++++++++++++++++++
>  src/cpu/cpu.h            |  8 ++++++++
>  src/cpu/cpu_x86.c        | 25 +++++++++++++++++++++++++
>  src/libvirt_private.syms |  1 +
>  4 files changed, 63 insertions(+)
> 
> diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c
> index 93647a2ed..1cc68f142 100644
> --- a/src/cpu/cpu.c
> +++ b/src/cpu/cpu.c
> @@ -1130,3 +1130,32 @@ virCPUExpandFeatures(virArch arch,
>      VIR_DEBUG("nfeatures=%zu", cpu->nfeatures);
>      return 0;
>  }
> +
> +
> +/**
> + * virCPUCopyMigratable:
> + *
> + * @arch: CPU architecture
> + * @cpu: CPU definition to be copied
> + *
> + * Makes a copy of @cpu with all features which would block migration removed.
> + *
> + * Returns the copy of the CPU or NULL on error.
> + */
> +virCPUDefPtr
> +virCPUCopyMigratable(virArch arch,
> +                     virCPUDefPtr cpu)
> +{
> +    struct cpuArchDriver *driver;
> +
> +    VIR_DEBUG("arch=%s, cpu=%p, model=%s",
> +              virArchToString(arch), cpu, NULLSTR(cpu->model));
> +
> +    if (!(driver = cpuGetSubDriver(arch)))
> +        return NULL;
> +
> +    if (driver->copyMigratable)
> +        return driver->copyMigratable(cpu);
> +    else
> +        return virCPUDefCopy(cpu);

Not quite sure I read the function comments similarly with respect to
what the code is doing (and peeking ahead to patch 5 where this is first
called).

Essentially this API either makes a 'migratable' version of a virCPUDef
or it just copies the (eventually called) "full" version of a virCPUDef
for architectures that don't support or need to change the "full"
virCPUDef to disable migratability features...  (If I've read the tea
leaves right of course ;-))

ACK with that adjustment,

John





More information about the libvir-list mailing list