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@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