Features/CPUHotplug

Summary

This feature is about allowing CPU hotplug in QEMU.

Owner

• Name: Igor Mammedov
• Email: imammedo@redhat.com

Detailed Summary

It was proposed to use device-add/device-del interface for hot-plugging CPUs instead of using it's own interface. For this to work CPUs should become child of Device and do not require external calls for creating or initializing it.

X86CPU Hot-Add Dependencies and ToDo-s

^{Legend: green - done, blue - in progress, red - TBD}

• External CPU clean-ups. Move CPU internals inside CPU object
  • move tcg init code CPU. commits d65e98, 84e3b60, eeec69d, 130a038
  • move CPU reset from board level into CPU. commits 65dee3805, dd673288
  • move APIC creation/initialization into CPU object. commit [ bdeec8021]

• CPU as Device [commit: 961f839]
  • necessary for converting "CPUID features" into static properties
  • allows to use device_add command after CPU subclasses is implemented.

• QOM realize, device-only
  • http://permalink.gmane.org/gmane.comp.emulators.qemu/187533
  • convert CPUs realizefn() to use DeviceRealize

• CPUID features as properties
  • provides an ability to set/get features using common FEAT_FOO=VAL property interfaces.
  • Features related clean-ups and code reorganisation:
    • move feature flags fix-ups & checks to realize time
      • in OQM model any feature/property could be amended until realize time. Masking out unsupported kvm/tcg features too early could lead to invalid features to be exposed to guest
      • 9b15cd9 target-i386: Sanitize AMD's ext2_features at realize time
      • 4586f15 target-i386: Filter out unsupported features at realize time
    • separate features parsing from setting defaults
      • clean-up cpu_x86_parse_featurestr(), leaving in it only custom features parsing that should be set on CPU instance after all defaults are set. Later defaults initialization should be moved to CPU sub-classes and custom legacy features parser cpu_x86_parse_featurestr() could be converted to setting global properties, when CPU features are converted into static properties.
      • Patches: http://permalink.gmane.org/gmane.comp.emulators.qemu/188062
  • Conversion of features and other properties into static properties provides following benefits:
    • global properties for CPU
    • setting defaults using default values of static properties, could be used in CPU subclasses
    • latest implementation based on qom-cpu tree: [1]

• CPU models as CPU subclasses
  • gives ability to create CPUs using CPU subclass name without any ad-hoc calls.
  • there are several implementations in qemu-devel with following open questions:
    • issue 1: in KVM mode qemu provides host CPU model. This model depends on kvm being initialized before CPU could be created due to dependency on kvm_arch_get_supported_cpuid(). Due to lazy type initialization it usually doesn't cause problem because CPUs are created after kvm_init(). However if qemu is called with options -enable-kvm -cpu help, it should display host model as available. With introduction of CPU sub-classes, host's cpu model type should be registered only when kvm is enabled, introducing dependency on kvm_init() being called first. The same issue applies to type introspection when it will be available.
    • issue 2: when qemu is started with -enable-kvm and vendor feature is not overridden with on command line, built-in vendor is replaced with host's vendor [see commit 8935499831312]. Again with lazy type initialization it doesn't cause problem because kvm_init() is called before type's class_init() is called, so class_init() could overwrite built-in vendor with host's value. But if type introspection wouldn't require instantiated machine /i.e. be like -cpu help/ it could cause problem that even with -enable-kvm it would return built-in vendor values instead of host's due to the lack of option dependencies which would say that -enable-kvm should be processed before '-show-types' or something like this over other interfaces.