Commit de024815e3 (target-i386: QOM'ify
CPU init) moved mce_init() call from helper.c:cpu_x86_init() into
X86CPU's cpu.c:x86_cpu_initfn().
mce_init() checks for a family >= 6 though, so we could end up with a
sequence such as for -cpu somecpu,family=6:
x86_cpu_initfn => X86CPU::family == 5
mce_init => no-op
cpu_x86_register => X86CPU::family = 6
=> MCE unexpectedly not init'ed
or for -cpu someothercpu,family=5:
x86_cpu_initfn => X86CPU::family == 6
mce_init => init'ed
cpu_x86_register => X86CPU::family = 5
=> MCE unexpectedly init'ed
Therefore partially revert the above commit. To avoid moving
mce_init() back into helper.c, foresightedly move it into a
new x86_cpu_realize() function and, in lack of ObjectClass::realize,
call it directly from cpu_x86_init().
While at it, move the qemu_init_vcpu() call that used to follow
mce_init() in cpu_x86_init() into the new realizefn as well.
Reported-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Use Hz as unit.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Using it now would incur converting the three x86_def_t vendor words
into a string for object_property_set_str(), then back to three words
in the "vendor" setter.
The built-in CPU definitions use numeric preprocessor defines to
initialize the three words in a charset-safe way, so do not change the
fields to char[12] just to use the setter.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Add the property early in the initfn so that it can be used in helpers
such as mce_init().
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
[AF: Add an error_free(), spotted by Michael Roth]
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
A family field value of 0xf and extended family field value of 0xff is
the maximum representable unsigned family number.
All other CPUID property values are bounds-checked, so add a check here
for symmetry before we adopt it in a property setter.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Avoids an x86_env_get_cpu() call there, to work with QOM properties.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Don't assume zeroed cpuid_model[] fields.
This didn't break anything yet but QOM properties should be able to set
the value to something else without setting an intermediate zero string.
Reviewed-by: Eduardo Habhost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
[AF: Use memset() instead of for loop, suggested by Igor]
Signed-off-by: Andreas Färber <afaerber@suse.de>
Move code from cpu_x86_init() to new QOM x86_cpu_initfn().
Also move mce_init() to cpu.c since it's used nowhere else.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Embed CPUX86State as first member of X86CPU.
Distinguish between "x86_64-cpu" and "i386-cpu".
Drop cpu_x86_close() in favor of calling object_delete() directly.
For now let CPUClass::reset() call cpu_state_reset().
Signed-off-by: Andreas Färber <afaerber@suse.de>
