Quoting Jiri Denemark (2018-07-12 06:59:18)
On Mon, Jul 09, 2018 at 22:56:47 -0500, Chris Venteicher wrote:
Renamed variable in CPUModelInfo such that props_migratable_valid is true when properties in CPUModelInfo have been updated to accurately indicate if property is / isn't migratable.
Property migratability is not returned directly in QMP messages but rather is sometimes calculated within Libvirt by other means and then stored in CPUModelInfo properties by Libvirt. props_migratable_valid is set to true when this calculation has been done by Libvirt. --- src/qemu/qemu_capabilities.c | 10 +++++----- src/qemu/qemu_monitor.c | 2 +- src/qemu/qemu_monitor.h | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)
...
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 18b59be985..208a7f5d21 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -1005,7 +1005,7 @@ struct _qemuMonitorCPUModelInfo { char *name; size_t nprops; qemuMonitorCPUPropertyPtr props; - bool migratability; + bool props_migratable_valid; };
I don't see a reason for renaming the variable. The new name is uglier and may be confusing in exactly the same way you found migratability to be confusing. Just add a comment which would explain that the migratability tells whether we can use the prop->migratable value to check if a particular feature is migratable.
I still have some concerns about the use of the migratability (props_migratability_valid) variable. There seems to be a very narrow case where the CPUModelInfo is non-migratable (contains non-migratable props) ... arch:X86 + name:host. In all other cases, specific model names (ex IvyBridge) or other Archs, the CPUModelInfo is by default migratable yet the variable migratability (props_migratable_valid) is false. There seems to be multiple cases in existing code base where the CPUModelInfo is actually migratable but is treated as non-migratable because the migratability (props_migratability_valid) is false. Not sure if this is really a problem or if I am just missing something yet. Seems like the most efficient thing is to try to sort it out in a stand alone patch that's easy to give feedback on. Regardless, I will try to keep the naming consistent (migratability) and use a comment if needed. Chris
Jirka