qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH qom-cpu-next v4 0/5] target-i386: X86CPU subclasses


From: Igor Mammedov
Subject: [Qemu-devel] [PATCH qom-cpu-next v4 0/5] target-i386: X86CPU subclasses
Date: Tue, 5 Feb 2013 17:39:19 +0100

It was noticed that in theory a QOM class enumeration could lead to the host
CPU class_init running before kvm_init(). But currently such enumeration
happens only on '-cpu ?' and it doesn't print neither 'host' cpu nor dumps
each cpu_model vendor value. If we ever would need to print 'host' name on
'-cpu ?' we could move list_cpus() after kvm_init().

Proposal is to keep it this way and cover a second use case where CPU
classes are initialized after possible kvm_init(). If user wants
introspect default values of CPU classes with kvm mode default overrides
it should do so with KVM initialized first.

Similar to target-ppc, -cpu host code is placed into kvm.c rather than cpu.c.

This conversion is an interim solution to get the code structured in a
QOM-friendly way and to reach a hot-plug friendly and cross-target aligned
CPU initialization. It decouples the work of introducing subclasses (to hide
object initialization from cpu_init() and device_add) from any x86-internal
improvements (like Igor's global compat properties set from pc-x.y machines).
The -cpu ? and QMP support is still based on array iteration.

Based on qom-cpu-next todays queue.

Available for testing here:
https://github.com/imammedo/qemu/tree/x86-cpu-classes.afaerber.v4

v3 -> v4:
* register host CPU type in kvm_arch_init(), not expose broken type
  if KVM is not available.
* remove call of host's class_init() from kvm_arch_init()
* copy KVM specific overrides/defaults from host CPU type in 
x86_cpu_def_class_init()
* consolidate exit path in cpu_x86_init()
* remove 'host' hack x86_cpu_class_by_name(), treat it as an ordinary CPU

v2 -> v3:
* Instead of re-coding all CPU definitions as class_init functions, leave
  the built-in definition array in place and place x86_def_t in the class.
* Use kvm_arch_init() hook to assure class_init succeeds for -cpu host.
  Suggested by Eduardo.

v1-> v2:
* Instead of turning x86_def_t into X86CPUInfo to initialize classes,
  drop it completely and register types manually with customizable TypeInfos
* Use new list facilities for printing -cpu ? models
* Adopt new name scheme suggested by Eduardo and ideas from my alpha series
* Keep short names in -cpu ? output for alignment reasons
* Merge cpu_x86_init() into cpu.c:cpu_x86_register()
* Append patch showing Haswell as subclass of SandyBridge


Cc: Anthony Liguori <address@hidden>
Cc: Eduardo Habkost <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Blue Swirl <address@hidden>
Cc: Richard Henderson <address@hidden>
Cc: Andreas Färber <address@hidden>

Andreas Färber (4):
  target-i386: Move cpu_x86_init()
  target-i386: Split command line parsing out of cpu_x86_register()
  target-i386: Slim conversion to X86CPU subclasses
  Remove cpudef_setup() hooks

Igor Mammedov (1):
  target-i386: fix kvm_default_features overwriting
    kvm_arch_get_supported_cpuid()

 arch_init.c                |    7 -
 bsd-user/main.c            |    3 -
 include/sysemu/arch_init.h |    1 -
 linux-user/main.c          |    3 -
 target-i386/cpu-qom.h      |   24 +++
 target-i386/cpu.c          |  340 ++++++++++++++++++--------------------------
 target-i386/cpu.h          |    8 +-
 target-i386/helper.c       |   24 ---
 target-i386/kvm.c          |   72 ++++++++++
 vl.c                       |    7 -
 10 files changed, 238 insertions(+), 251 deletions(-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]