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@xxxxxxxxxx>
> ---
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
