Features/CPUHotplug: Difference between revisions

From QEMU
No edit summary
Line 45: Line 45:


* <span style="color:blue">CPU models as CPU subclasses</span>
* <span style="color:blue">CPU models as CPU subclasses</span>
** should provide complete QOM object interface to CPU subclasses.
** gives ability to create CPUs using CPU subclass name without any ad-hoc calls.
** gives ability to create/initialize 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:

Revision as of 19:01, 14 January 2013

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 - to be implemented

  • 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.
  • 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: