2012-04-02 13:39:23 +04:00
|
|
|
/*
|
|
|
|
* QEMU S/390 CPU
|
|
|
|
*
|
2012-04-02 15:31:59 +04:00
|
|
|
* Copyright (c) 2009 Ulrich Hecht
|
|
|
|
* Copyright (c) 2011 Alexander Graf
|
2012-04-02 13:39:23 +04:00
|
|
|
* Copyright (c) 2012 SUSE LINUX Products GmbH
|
2013-01-07 09:27:14 +04:00
|
|
|
* Copyright (c) 2012 IBM Corp.
|
2012-04-02 13:39:23 +04:00
|
|
|
*
|
2019-02-06 15:41:33 +03:00
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
2012-04-02 13:39:23 +04:00
|
|
|
*
|
2019-02-06 15:41:33 +03:00
|
|
|
* This program is distributed in the hope that it will be useful,
|
2012-04-02 13:39:23 +04:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
2019-02-06 15:41:33 +03:00
|
|
|
* General Public License for more details.
|
2012-04-02 13:39:23 +04:00
|
|
|
*
|
2019-02-06 15:41:33 +03:00
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, see <http://www.gnu.org/licenses/>.
|
2012-04-02 13:39:23 +04:00
|
|
|
*/
|
|
|
|
|
2016-01-26 21:17:00 +03:00
|
|
|
#include "qemu/osdep.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 11:01:28 +03:00
|
|
|
#include "qapi/error.h"
|
2012-05-03 06:13:04 +04:00
|
|
|
#include "cpu.h"
|
2017-08-18 14:43:49 +03:00
|
|
|
#include "internal.h"
|
2017-08-18 14:43:52 +03:00
|
|
|
#include "kvm_s390x.h"
|
|
|
|
#include "sysemu/kvm.h"
|
2019-08-12 08:23:38 +03:00
|
|
|
#include "sysemu/reset.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/timer.h"
|
2014-09-30 12:57:29 +04:00
|
|
|
#include "qemu/error-report.h"
|
2019-05-23 17:35:07 +03:00
|
|
|
#include "qemu/module.h"
|
2014-09-30 12:57:29 +04:00
|
|
|
#include "trace.h"
|
2016-03-04 20:34:34 +03:00
|
|
|
#include "qapi/visitor.h"
|
2019-06-19 23:10:41 +03:00
|
|
|
#include "qapi/qapi-types-machine.h"
|
2018-02-27 02:13:27 +03:00
|
|
|
#include "qapi/qapi-visit-run-state.h"
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
#include "sysemu/hw_accel.h"
|
2017-09-13 16:24:08 +03:00
|
|
|
#include "hw/qdev-properties.h"
|
2013-01-20 22:41:06 +04:00
|
|
|
#ifndef CONFIG_USER_ONLY
|
2020-03-23 11:36:06 +03:00
|
|
|
#include "hw/s390x/pv.h"
|
2019-05-18 23:54:24 +03:00
|
|
|
#include "hw/boards.h"
|
2012-12-18 11:50:59 +04:00
|
|
|
#include "sysemu/arch_init.h"
|
2016-03-04 20:34:34 +03:00
|
|
|
#include "sysemu/sysemu.h"
|
2019-05-23 17:35:05 +03:00
|
|
|
#include "sysemu/tcg.h"
|
2012-12-18 11:50:59 +04:00
|
|
|
#endif
|
2019-08-08 19:30:35 +03:00
|
|
|
#include "fpu/softfloat-helpers.h"
|
2020-01-04 00:24:59 +03:00
|
|
|
#include "disas/capstone.h"
|
2012-12-18 11:50:59 +04:00
|
|
|
|
2013-01-07 09:27:14 +04:00
|
|
|
#define CR0_RESET 0xE0UL
|
|
|
|
#define CR14_RESET 0xC2000000UL;
|
|
|
|
|
2013-06-21 21:09:18 +04:00
|
|
|
static void s390_cpu_set_pc(CPUState *cs, vaddr value)
|
|
|
|
{
|
|
|
|
S390CPU *cpu = S390_CPU(cs);
|
|
|
|
|
|
|
|
cpu->env.psw.addr = value;
|
|
|
|
}
|
|
|
|
|
2013-08-25 20:53:55 +04:00
|
|
|
static bool s390_cpu_has_work(CPUState *cs)
|
|
|
|
{
|
|
|
|
S390CPU *cpu = S390_CPU(cs);
|
|
|
|
|
2017-09-28 23:36:44 +03:00
|
|
|
/* STOPPED cpus can never wake up */
|
qmp: expose s390-specific CPU info
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[
{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}
]
This change doesn't add the s390-specific data to HMP 'info cpus'.
A follow-on patch will remove all architecture specific information
from there.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-16 19:08:37 +03:00
|
|
|
if (s390_cpu_get_state(cpu) != S390_CPU_STATE_LOAD &&
|
|
|
|
s390_cpu_get_state(cpu) != S390_CPU_STATE_OPERATING) {
|
2017-09-28 23:36:44 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-09-28 23:36:42 +03:00
|
|
|
if (!(cs->interrupt_request & CPU_INTERRUPT_HARD)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return s390_cpu_has_int(cpu);
|
2013-08-25 20:53:55 +04:00
|
|
|
}
|
|
|
|
|
2013-07-25 18:45:51 +04:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
|
|
|
/* S390CPUClass::load_normal() */
|
|
|
|
static void s390_cpu_load_normal(CPUState *s)
|
|
|
|
{
|
|
|
|
S390CPU *cpu = S390_CPU(s);
|
2020-03-19 16:19:15 +03:00
|
|
|
uint64_t spsw;
|
|
|
|
|
|
|
|
if (!s390_is_pv()) {
|
|
|
|
spsw = ldq_phys(s->as, 0);
|
|
|
|
cpu->env.psw.mask = spsw & PSW_MASK_SHORT_CTRL;
|
|
|
|
/*
|
|
|
|
* Invert short psw indication, so SIE will report a specification
|
|
|
|
* exception if it was not set.
|
|
|
|
*/
|
|
|
|
cpu->env.psw.mask ^= PSW_MASK_SHORTPSW;
|
|
|
|
cpu->env.psw.addr = spsw & PSW_MASK_SHORT_ADDR;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Firmware requires us to set the load state before we set
|
|
|
|
* the cpu to operating on protected guests.
|
|
|
|
*/
|
|
|
|
s390_cpu_set_state(S390_CPU_STATE_LOAD, cpu);
|
|
|
|
}
|
qmp: expose s390-specific CPU info
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[
{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}
]
This change doesn't add the s390-specific data to HMP 'info cpus'.
A follow-on patch will remove all architecture specific information
from there.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-16 19:08:37 +03:00
|
|
|
s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
|
2013-07-25 18:45:51 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-11-27 20:50:42 +03:00
|
|
|
/* S390CPUClass::reset() */
|
|
|
|
static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
|
2012-04-02 13:39:23 +04:00
|
|
|
{
|
|
|
|
S390CPU *cpu = S390_CPU(s);
|
|
|
|
S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
|
|
|
|
CPUS390XState *env = &cpu->env;
|
cpu: Use DeviceClass reset instead of a special CPUClass reset
The CPUClass has a 'reset' method. This is a legacy from when
TYPE_CPU used not to inherit from TYPE_DEVICE. We don't need it any
more, as we can simply use the TYPE_DEVICE reset. The 'cpu_reset()'
function is kept as the API which most places use to reset a CPU; it
is now a wrapper which calls device_cold_reset() and then the
tracepoint function.
This change should not cause CPU objects to be reset more often
than they are at the moment, because:
* nobody is directly calling device_cold_reset() or
qdev_reset_all() on CPU objects
* no CPU object is on a qbus, so they will not be reset either
by somebody calling qbus_reset_all()/bus_cold_reset(), or
by the main "reset sysbus and everything in the qbus tree"
reset that most devices are reset by
Note that this does not change the need for each machine or whatever
to use qemu_register_reset() to arrange to call cpu_reset() -- that
is necessary because CPU objects are not on any qbus, so they don't
get reset when the qbus tree rooted at the sysbus bus is reset, and
this isn't being changed here.
All the changes to the files under target/ were made using the
included Coccinelle script, except:
(1) the deletion of the now-inaccurate and not terribly useful
"CPUClass::reset" comments was done with a perl one-liner afterwards:
perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c
(2) this bit of the s390 change was done by hand, because the
Coccinelle script is not sophisticated enough to handle the
parent_reset call being inside another function:
| @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
| S390CPU *cpu = S390_CPU(s);
| S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
| CPUS390XState *env = &cpu->env;
|+ DeviceState *dev = DEVICE(s);
|
|- scc->parent_reset(s);
|+ scc->parent_reset(dev);
| cpu->env.sigp_order = 0;
| s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-03 13:05:11 +03:00
|
|
|
DeviceState *dev = DEVICE(s);
|
2012-04-02 13:39:23 +04:00
|
|
|
|
cpu: Use DeviceClass reset instead of a special CPUClass reset
The CPUClass has a 'reset' method. This is a legacy from when
TYPE_CPU used not to inherit from TYPE_DEVICE. We don't need it any
more, as we can simply use the TYPE_DEVICE reset. The 'cpu_reset()'
function is kept as the API which most places use to reset a CPU; it
is now a wrapper which calls device_cold_reset() and then the
tracepoint function.
This change should not cause CPU objects to be reset more often
than they are at the moment, because:
* nobody is directly calling device_cold_reset() or
qdev_reset_all() on CPU objects
* no CPU object is on a qbus, so they will not be reset either
by somebody calling qbus_reset_all()/bus_cold_reset(), or
by the main "reset sysbus and everything in the qbus tree"
reset that most devices are reset by
Note that this does not change the need for each machine or whatever
to use qemu_register_reset() to arrange to call cpu_reset() -- that
is necessary because CPU objects are not on any qbus, so they don't
get reset when the qbus tree rooted at the sysbus bus is reset, and
this isn't being changed here.
All the changes to the files under target/ were made using the
included Coccinelle script, except:
(1) the deletion of the now-inaccurate and not terribly useful
"CPUClass::reset" comments was done with a perl one-liner afterwards:
perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c
(2) this bit of the s390 change was done by hand, because the
Coccinelle script is not sophisticated enough to handle the
parent_reset call being inside another function:
| @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
| S390CPU *cpu = S390_CPU(s);
| S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
| CPUS390XState *env = &cpu->env;
|+ DeviceState *dev = DEVICE(s);
|
|- scc->parent_reset(s);
|+ scc->parent_reset(dev);
| cpu->env.sigp_order = 0;
| s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-03 13:05:11 +03:00
|
|
|
scc->parent_reset(dev);
|
2015-02-24 16:15:27 +03:00
|
|
|
cpu->env.sigp_order = 0;
|
qmp: expose s390-specific CPU info
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[
{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}
]
This change doesn't add the s390-specific data to HMP 'info cpus'.
A follow-on patch will remove all architecture specific information
from there.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-16 19:08:37 +03:00
|
|
|
s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
|
2019-11-27 20:50:42 +03:00
|
|
|
|
|
|
|
switch (type) {
|
2019-11-27 20:50:44 +03:00
|
|
|
case S390_CPU_RESET_CLEAR:
|
|
|
|
memset(env, 0, offsetof(CPUS390XState, start_initial_reset_fields));
|
|
|
|
/* fall through */
|
2019-11-28 11:37:23 +03:00
|
|
|
case S390_CPU_RESET_INITIAL:
|
|
|
|
/* initial reset does not clear everything! */
|
|
|
|
memset(&env->start_initial_reset_fields, 0,
|
2019-12-03 16:28:12 +03:00
|
|
|
offsetof(CPUS390XState, start_normal_reset_fields) -
|
2019-11-28 11:37:23 +03:00
|
|
|
offsetof(CPUS390XState, start_initial_reset_fields));
|
|
|
|
|
|
|
|
/* architectured initial value for Breaking-Event-Address register */
|
|
|
|
env->gbea = 1;
|
|
|
|
|
|
|
|
/* architectured initial values for CR 0 and 14 */
|
|
|
|
env->cregs[0] = CR0_RESET;
|
|
|
|
env->cregs[14] = CR14_RESET;
|
|
|
|
|
2019-11-27 20:50:44 +03:00
|
|
|
#if defined(CONFIG_USER_ONLY)
|
|
|
|
/* user mode should always be allowed to use the full FPU */
|
|
|
|
env->cregs[0] |= CR0_AFP;
|
|
|
|
if (s390_has_feat(S390_FEAT_VECTOR)) {
|
|
|
|
env->cregs[0] |= CR0_VECTOR;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-11-28 11:37:23 +03:00
|
|
|
/* tininess for underflow is detected before rounding */
|
|
|
|
set_float_detect_tininess(float_tininess_before_rounding,
|
|
|
|
&env->fpu_status);
|
|
|
|
/* fall through */
|
2019-11-27 20:50:42 +03:00
|
|
|
case S390_CPU_RESET_NORMAL:
|
2019-12-03 16:28:12 +03:00
|
|
|
env->psw.mask &= ~PSW_MASK_RI;
|
|
|
|
memset(&env->start_normal_reset_fields, 0,
|
|
|
|
offsetof(CPUS390XState, end_reset_fields) -
|
|
|
|
offsetof(CPUS390XState, start_normal_reset_fields));
|
|
|
|
|
2019-11-27 20:50:42 +03:00
|
|
|
env->pfault_token = -1UL;
|
|
|
|
env->bpbc = false;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
g_assert_not_reached();
|
|
|
|
}
|
2015-05-25 02:47:26 +03:00
|
|
|
|
2014-02-12 12:56:35 +04:00
|
|
|
/* Reset state inside the kernel that we cannot access yet from QEMU. */
|
2020-02-14 18:16:21 +03:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
switch (type) {
|
|
|
|
case S390_CPU_RESET_CLEAR:
|
|
|
|
kvm_s390_reset_vcpu_clear(cpu);
|
|
|
|
break;
|
|
|
|
case S390_CPU_RESET_INITIAL:
|
|
|
|
kvm_s390_reset_vcpu_initial(cpu);
|
|
|
|
break;
|
|
|
|
case S390_CPU_RESET_NORMAL:
|
|
|
|
kvm_s390_reset_vcpu_normal(cpu);
|
|
|
|
break;
|
|
|
|
}
|
2014-02-12 12:56:35 +04:00
|
|
|
}
|
s390/cpu: split CPU reset into architectured functions
s390 provides several CPU resets:
- CPU reset, clears interrupts, stop processing, clears TLB, but does
not touch registers
- initial CPU reset, like CPU reset, but also clears PSW, prefix, FPC,
timer and control registers. It does not touch gprs, fprs and acrs (!)
- Power on reset: the full monty
wire up CPUClass reset to the full monty, but provide the lesser resets
as part of S390CPUClass.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-06-28 12:51:09 +04:00
|
|
|
}
|
|
|
|
|
2013-01-07 09:27:14 +04:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
|
|
|
static void s390_cpu_machine_reset_cb(void *opaque)
|
|
|
|
{
|
|
|
|
S390CPU *cpu = opaque;
|
|
|
|
|
2016-10-31 12:36:08 +03:00
|
|
|
run_on_cpu(CPU(cpu), s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
|
2013-01-07 09:27:14 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-07-12 04:59:58 +03:00
|
|
|
static void s390_cpu_disas_set_info(CPUState *cpu, disassemble_info *info)
|
|
|
|
{
|
|
|
|
info->mach = bfd_mach_s390_64;
|
|
|
|
info->print_insn = print_insn_s390;
|
2020-01-04 00:24:59 +03:00
|
|
|
info->cap_arch = CS_ARCH_SYSZ;
|
|
|
|
info->cap_insn_unit = 2;
|
|
|
|
info->cap_insn_split = 6;
|
2015-07-12 04:59:58 +03:00
|
|
|
}
|
|
|
|
|
2013-01-16 07:00:41 +04:00
|
|
|
static void s390_cpu_realizefn(DeviceState *dev, Error **errp)
|
|
|
|
{
|
2013-07-27 04:53:25 +04:00
|
|
|
CPUState *cs = CPU(dev);
|
2013-01-16 07:00:41 +04:00
|
|
|
S390CPUClass *scc = S390_CPU_GET_CLASS(dev);
|
2017-09-28 16:46:08 +03:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
2016-03-04 20:34:31 +03:00
|
|
|
S390CPU *cpu = S390_CPU(dev);
|
2017-09-28 16:46:08 +03:00
|
|
|
#endif
|
2016-03-04 20:34:31 +03:00
|
|
|
Error *err = NULL;
|
|
|
|
|
2016-09-05 11:52:16 +03:00
|
|
|
/* the model has to be realized before qemu_init_vcpu() due to kvm */
|
|
|
|
s390_realize_cpu_model(cs, &err);
|
|
|
|
if (err) {
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2016-03-04 20:34:34 +03:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
2019-05-18 23:54:24 +03:00
|
|
|
MachineState *ms = MACHINE(qdev_get_machine());
|
|
|
|
unsigned int max_cpus = ms->smp.max_cpus;
|
2017-09-13 16:24:08 +03:00
|
|
|
if (cpu->env.core_id >= max_cpus) {
|
|
|
|
error_setg(&err, "Unable to add CPU with core-id: %" PRIu32
|
|
|
|
", maximum core-id: %d", cpu->env.core_id,
|
|
|
|
max_cpus - 1);
|
2016-03-04 20:34:34 +03:00
|
|
|
goto out;
|
|
|
|
}
|
2017-09-13 16:24:07 +03:00
|
|
|
|
2017-09-13 16:24:08 +03:00
|
|
|
if (cpu_exists(cpu->env.core_id)) {
|
|
|
|
error_setg(&err, "Unable to add CPU with core-id: %" PRIu32
|
|
|
|
", it already exists", cpu->env.core_id);
|
2016-03-04 20:34:34 +03:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2017-09-13 16:24:08 +03:00
|
|
|
/* sync cs->cpu_index and env->core_id. The latter is needed for TCG. */
|
2017-09-28 16:46:08 +03:00
|
|
|
cs->cpu_index = cpu->env.core_id;
|
|
|
|
#endif
|
|
|
|
|
2016-10-20 14:26:03 +03:00
|
|
|
cpu_exec_realizefn(cs, &err);
|
2016-03-04 20:34:31 +03:00
|
|
|
if (err != NULL) {
|
2016-03-04 20:34:34 +03:00
|
|
|
goto out;
|
2016-03-04 20:34:31 +03:00
|
|
|
}
|
2013-01-16 07:00:41 +04:00
|
|
|
|
2016-03-04 20:34:31 +03:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
|
|
|
qemu_register_reset(s390_cpu_machine_reset_cb, cpu);
|
|
|
|
#endif
|
2014-08-29 17:52:16 +04:00
|
|
|
s390_cpu_gdb_init(cs);
|
2013-07-27 04:53:25 +04:00
|
|
|
qemu_init_vcpu(cs);
|
2018-06-27 16:44:10 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* KVM requires the initial CPU reset ioctl to be executed on the target
|
|
|
|
* CPU thread. CPU hotplug under single-threaded TCG will not work with
|
|
|
|
* run_on_cpu(), as run_on_cpu() will not work properly if called while
|
|
|
|
* the main thread is already running but the CPU hasn't been realized.
|
|
|
|
*/
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
run_on_cpu(cs, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
|
|
|
|
} else {
|
|
|
|
cpu_reset(cs);
|
|
|
|
}
|
2013-01-16 07:00:41 +04:00
|
|
|
|
2016-03-04 20:34:34 +03:00
|
|
|
scc->parent_realize(dev, &err);
|
|
|
|
out:
|
|
|
|
error_propagate(errp, err);
|
|
|
|
}
|
|
|
|
|
2020-05-22 20:25:08 +03:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
static GuestPanicInformation *s390_cpu_get_crash_info(CPUState *cs)
|
|
|
|
{
|
|
|
|
GuestPanicInformation *panic_info;
|
|
|
|
S390CPU *cpu = S390_CPU(cs);
|
|
|
|
|
|
|
|
cpu_synchronize_state(cs);
|
|
|
|
panic_info = g_malloc0(sizeof(GuestPanicInformation));
|
|
|
|
|
|
|
|
panic_info->type = GUEST_PANIC_INFORMATION_TYPE_S390;
|
|
|
|
panic_info->u.s390.core = cpu->env.core_id;
|
|
|
|
panic_info->u.s390.psw_mask = cpu->env.psw.mask;
|
|
|
|
panic_info->u.s390.psw_addr = cpu->env.psw.addr;
|
|
|
|
panic_info->u.s390.reason = cpu->env.crash_reason;
|
|
|
|
|
|
|
|
return panic_info;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void s390_cpu_get_crash_info_qom(Object *obj, Visitor *v,
|
|
|
|
const char *name, void *opaque,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
CPUState *cs = CPU(obj);
|
|
|
|
GuestPanicInformation *panic_info;
|
|
|
|
|
|
|
|
if (!cs->crash_occurred) {
|
|
|
|
error_setg(errp, "No crash occurred");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
panic_info = s390_cpu_get_crash_info(cs);
|
|
|
|
|
|
|
|
visit_type_GuestPanicInformation(v, "crash-information", &panic_info,
|
|
|
|
errp);
|
|
|
|
qapi_free_GuestPanicInformation(panic_info);
|
|
|
|
}
|
2020-05-22 20:25:08 +03:00
|
|
|
#endif
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
|
2012-04-02 15:56:29 +04:00
|
|
|
static void s390_cpu_initfn(Object *obj)
|
|
|
|
{
|
2013-01-17 15:13:41 +04:00
|
|
|
CPUState *cs = CPU(obj);
|
2012-04-02 15:56:29 +04:00
|
|
|
S390CPU *cpu = S390_CPU(obj);
|
|
|
|
|
2019-03-29 00:26:22 +03:00
|
|
|
cpu_set_cpustate_pointers(cpu);
|
2016-03-04 20:34:30 +03:00
|
|
|
cs->exception_index = EXCP_HLT;
|
2020-05-22 20:25:08 +03:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
2020-08-26 08:55:35 +03:00
|
|
|
cs->start_powered_off = true;
|
s390x/cpu: expose the guest crash information
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
(QEMU) (QEMU) qom-get path=/machine/unattached/device[0] \
property=crash-information
{"return": {"core": 0, "reason": "disabled-wait", "psw-mask": 562956395872256, \
"type": "s390", "psw-addr": 1102832}}
2. GUEST_PANICKED event reporting;
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
{
"timestamp": {
"seconds": 1518004739,
"microseconds": 552563
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"core": 0,
"psw-addr": 1102832,
"reason": "disabled-wait",
"psw-mask": 562956395872256,
"type": "s390"
}
}
}
3. log;
Run qemu with the parameters: -D <logfile> -d guest_errors, to
specify the logfile and log item. The results might be,
Guest crashed on cpu 0: disabled-wait
PSW: 0x0002000180000000 0x000000000010d3f0
Co-authored-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20180209122543.25755-1-borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[CH: tweaked qapi comment]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09 15:25:43 +03:00
|
|
|
object_property_add(obj, "crash-information", "GuestPanicInformation",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
s390_cpu_get_crash_info_qom, NULL, NULL, NULL);
|
2019-03-29 00:26:22 +03:00
|
|
|
cpu->env.tod_timer =
|
|
|
|
timer_new_ns(QEMU_CLOCK_VIRTUAL, s390x_tod_timer, cpu);
|
|
|
|
cpu->env.cpu_timer =
|
|
|
|
timer_new_ns(QEMU_CLOCK_VIRTUAL, s390x_cpu_timer, cpu);
|
qmp: expose s390-specific CPU info
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[
{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}
]
This change doesn't add the s390-specific data to HMP 'info cpus'.
A follow-on patch will remove all architecture specific information
from there.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-16 19:08:37 +03:00
|
|
|
s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
|
2012-04-02 15:56:29 +04:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2013-01-07 10:14:16 +04:00
|
|
|
static void s390_cpu_finalize(Object *obj)
|
|
|
|
{
|
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
|
|
|
S390CPU *cpu = S390_CPU(obj);
|
|
|
|
|
|
|
|
qemu_unregister_reset(s390_cpu_machine_reset_cb, cpu);
|
2015-03-02 19:44:24 +03:00
|
|
|
g_free(cpu->irqstate);
|
2013-01-07 10:14:16 +04:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2014-09-30 12:57:28 +04:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
2014-09-30 12:57:29 +04:00
|
|
|
static bool disabled_wait(CPUState *cpu)
|
|
|
|
{
|
|
|
|
return cpu->halted && !(S390_CPU(cpu)->env.psw.mask &
|
|
|
|
(PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK));
|
|
|
|
}
|
|
|
|
|
2014-09-30 12:57:28 +04:00
|
|
|
static unsigned s390_count_running_cpus(void)
|
|
|
|
{
|
|
|
|
CPUState *cpu;
|
|
|
|
int nr_running = 0;
|
|
|
|
|
|
|
|
CPU_FOREACH(cpu) {
|
|
|
|
uint8_t state = S390_CPU(cpu)->env.cpu_state;
|
qmp: expose s390-specific CPU info
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[
{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}
]
This change doesn't add the s390-specific data to HMP 'info cpus'.
A follow-on patch will remove all architecture specific information
from there.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-16 19:08:37 +03:00
|
|
|
if (state == S390_CPU_STATE_OPERATING ||
|
|
|
|
state == S390_CPU_STATE_LOAD) {
|
2014-09-30 12:57:29 +04:00
|
|
|
if (!disabled_wait(cpu)) {
|
|
|
|
nr_running++;
|
|
|
|
}
|
2014-09-30 12:57:28 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nr_running;
|
|
|
|
}
|
|
|
|
|
2014-09-30 12:57:29 +04:00
|
|
|
unsigned int s390_cpu_halt(S390CPU *cpu)
|
2014-09-30 12:57:28 +04:00
|
|
|
{
|
|
|
|
CPUState *cs = CPU(cpu);
|
2014-09-30 12:57:29 +04:00
|
|
|
trace_cpu_halt(cs->cpu_index);
|
2014-09-30 12:57:28 +04:00
|
|
|
|
2014-09-30 12:57:29 +04:00
|
|
|
if (!cs->halted) {
|
|
|
|
cs->halted = 1;
|
|
|
|
cs->exception_index = EXCP_HLT;
|
2014-09-30 12:57:28 +04:00
|
|
|
}
|
2014-09-30 12:57:29 +04:00
|
|
|
|
|
|
|
return s390_count_running_cpus();
|
2014-09-30 12:57:28 +04:00
|
|
|
}
|
|
|
|
|
2014-09-30 12:57:29 +04:00
|
|
|
void s390_cpu_unhalt(S390CPU *cpu)
|
2014-09-30 12:57:28 +04:00
|
|
|
{
|
|
|
|
CPUState *cs = CPU(cpu);
|
2014-09-30 12:57:29 +04:00
|
|
|
trace_cpu_unhalt(cs->cpu_index);
|
2014-09-30 12:57:28 +04:00
|
|
|
|
2014-09-30 12:57:29 +04:00
|
|
|
if (cs->halted) {
|
|
|
|
cs->halted = 0;
|
|
|
|
cs->exception_index = -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned int s390_cpu_set_state(uint8_t cpu_state, S390CPU *cpu)
|
|
|
|
{
|
|
|
|
trace_cpu_set_state(CPU(cpu)->cpu_index, cpu_state);
|
|
|
|
|
|
|
|
switch (cpu_state) {
|
qmp: expose s390-specific CPU info
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[
{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}
]
This change doesn't add the s390-specific data to HMP 'info cpus'.
A follow-on patch will remove all architecture specific information
from there.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-16 19:08:37 +03:00
|
|
|
case S390_CPU_STATE_STOPPED:
|
|
|
|
case S390_CPU_STATE_CHECK_STOP:
|
2014-09-30 12:57:29 +04:00
|
|
|
/* halt the cpu for common infrastructure */
|
|
|
|
s390_cpu_halt(cpu);
|
|
|
|
break;
|
qmp: expose s390-specific CPU info
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[
{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}
]
This change doesn't add the s390-specific data to HMP 'info cpus'.
A follow-on patch will remove all architecture specific information
from there.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-16 19:08:37 +03:00
|
|
|
case S390_CPU_STATE_OPERATING:
|
|
|
|
case S390_CPU_STATE_LOAD:
|
2017-09-28 23:37:08 +03:00
|
|
|
/*
|
|
|
|
* Starting a CPU with a PSW WAIT bit set:
|
|
|
|
* KVM: handles this internally and triggers another WAIT exit.
|
|
|
|
* TCG: will actually try to continue to run. Don't unhalt, will
|
|
|
|
* be done when the CPU actually has work (an interrupt).
|
|
|
|
*/
|
|
|
|
if (!tcg_enabled() || !(cpu->env.psw.mask & PSW_MASK_WAIT)) {
|
|
|
|
s390_cpu_unhalt(cpu);
|
|
|
|
}
|
2014-09-30 12:57:29 +04:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
error_report("Requested CPU state is not a valid S390 CPU state: %u",
|
|
|
|
cpu_state);
|
|
|
|
exit(1);
|
2014-09-30 12:57:28 +04:00
|
|
|
}
|
2014-09-30 12:57:30 +04:00
|
|
|
if (kvm_enabled() && cpu->env.cpu_state != cpu_state) {
|
|
|
|
kvm_s390_set_cpu_state(cpu, cpu_state);
|
|
|
|
}
|
2014-09-30 12:57:29 +04:00
|
|
|
cpu->env.cpu_state = cpu_state;
|
2014-09-30 12:57:28 +04:00
|
|
|
|
|
|
|
return s390_count_running_cpus();
|
|
|
|
}
|
2017-08-18 14:43:50 +03:00
|
|
|
|
|
|
|
int s390_set_memory_limit(uint64_t new_limit, uint64_t *hw_limit)
|
|
|
|
{
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
return kvm_s390_set_mem_limit(new_limit, hw_limit);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2019-04-17 14:31:42 +03:00
|
|
|
|
|
|
|
void s390_set_max_pagesize(uint64_t pagesize, Error **errp)
|
|
|
|
{
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
kvm_s390_set_max_pagesize(pagesize, errp);
|
|
|
|
}
|
|
|
|
}
|
2017-08-18 14:43:50 +03:00
|
|
|
|
|
|
|
void s390_cmma_reset(void)
|
|
|
|
{
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
kvm_s390_cmma_reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int s390_assign_subch_ioeventfd(EventNotifier *notifier, uint32_t sch_id,
|
|
|
|
int vq, bool assign)
|
|
|
|
{
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
return kvm_s390_assign_subch_ioeventfd(notifier, sch_id, vq, assign);
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void s390_crypto_reset(void)
|
|
|
|
{
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
kvm_s390_crypto_reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-18 14:43:51 +03:00
|
|
|
void s390_enable_css_support(S390CPU *cpu)
|
|
|
|
{
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
kvm_s390_enable_css_support(cpu);
|
|
|
|
}
|
|
|
|
}
|
2020-11-14 01:10:22 +03:00
|
|
|
|
|
|
|
void s390_do_cpu_set_diag318(CPUState *cs, run_on_cpu_data arg)
|
|
|
|
{
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
kvm_s390_set_diag318(cs, arg.host_ulong);
|
|
|
|
}
|
|
|
|
}
|
2014-09-30 12:57:28 +04:00
|
|
|
#endif
|
|
|
|
|
2015-12-03 15:14:41 +03:00
|
|
|
static gchar *s390_gdb_arch_name(CPUState *cs)
|
|
|
|
{
|
|
|
|
return g_strdup("s390:64-bit");
|
|
|
|
}
|
|
|
|
|
2017-09-13 16:24:08 +03:00
|
|
|
static Property s390x_cpu_properties[] = {
|
2017-09-28 16:46:08 +03:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
2017-09-13 16:24:08 +03:00
|
|
|
DEFINE_PROP_UINT32("core-id", S390CPU, env.core_id, 0),
|
2017-09-28 16:46:08 +03:00
|
|
|
#endif
|
2017-09-13 16:24:08 +03:00
|
|
|
DEFINE_PROP_END_OF_LIST()
|
|
|
|
};
|
|
|
|
|
cpu: Use DeviceClass reset instead of a special CPUClass reset
The CPUClass has a 'reset' method. This is a legacy from when
TYPE_CPU used not to inherit from TYPE_DEVICE. We don't need it any
more, as we can simply use the TYPE_DEVICE reset. The 'cpu_reset()'
function is kept as the API which most places use to reset a CPU; it
is now a wrapper which calls device_cold_reset() and then the
tracepoint function.
This change should not cause CPU objects to be reset more often
than they are at the moment, because:
* nobody is directly calling device_cold_reset() or
qdev_reset_all() on CPU objects
* no CPU object is on a qbus, so they will not be reset either
by somebody calling qbus_reset_all()/bus_cold_reset(), or
by the main "reset sysbus and everything in the qbus tree"
reset that most devices are reset by
Note that this does not change the need for each machine or whatever
to use qemu_register_reset() to arrange to call cpu_reset() -- that
is necessary because CPU objects are not on any qbus, so they don't
get reset when the qbus tree rooted at the sysbus bus is reset, and
this isn't being changed here.
All the changes to the files under target/ were made using the
included Coccinelle script, except:
(1) the deletion of the now-inaccurate and not terribly useful
"CPUClass::reset" comments was done with a perl one-liner afterwards:
perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c
(2) this bit of the s390 change was done by hand, because the
Coccinelle script is not sophisticated enough to handle the
parent_reset call being inside another function:
| @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
| S390CPU *cpu = S390_CPU(s);
| S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
| CPUS390XState *env = &cpu->env;
|+ DeviceState *dev = DEVICE(s);
|
|- scc->parent_reset(s);
|+ scc->parent_reset(dev);
| cpu->env.sigp_order = 0;
| s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-03 13:05:11 +03:00
|
|
|
static void s390_cpu_reset_full(DeviceState *dev)
|
2019-11-27 20:50:44 +03:00
|
|
|
{
|
cpu: Use DeviceClass reset instead of a special CPUClass reset
The CPUClass has a 'reset' method. This is a legacy from when
TYPE_CPU used not to inherit from TYPE_DEVICE. We don't need it any
more, as we can simply use the TYPE_DEVICE reset. The 'cpu_reset()'
function is kept as the API which most places use to reset a CPU; it
is now a wrapper which calls device_cold_reset() and then the
tracepoint function.
This change should not cause CPU objects to be reset more often
than they are at the moment, because:
* nobody is directly calling device_cold_reset() or
qdev_reset_all() on CPU objects
* no CPU object is on a qbus, so they will not be reset either
by somebody calling qbus_reset_all()/bus_cold_reset(), or
by the main "reset sysbus and everything in the qbus tree"
reset that most devices are reset by
Note that this does not change the need for each machine or whatever
to use qemu_register_reset() to arrange to call cpu_reset() -- that
is necessary because CPU objects are not on any qbus, so they don't
get reset when the qbus tree rooted at the sysbus bus is reset, and
this isn't being changed here.
All the changes to the files under target/ were made using the
included Coccinelle script, except:
(1) the deletion of the now-inaccurate and not terribly useful
"CPUClass::reset" comments was done with a perl one-liner afterwards:
perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c
(2) this bit of the s390 change was done by hand, because the
Coccinelle script is not sophisticated enough to handle the
parent_reset call being inside another function:
| @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
| S390CPU *cpu = S390_CPU(s);
| S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
| CPUS390XState *env = &cpu->env;
|+ DeviceState *dev = DEVICE(s);
|
|- scc->parent_reset(s);
|+ scc->parent_reset(dev);
| cpu->env.sigp_order = 0;
| s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-03 13:05:11 +03:00
|
|
|
CPUState *s = CPU(dev);
|
2019-11-27 20:50:44 +03:00
|
|
|
return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
|
|
|
|
}
|
|
|
|
|
2012-04-02 13:39:23 +04:00
|
|
|
static void s390_cpu_class_init(ObjectClass *oc, void *data)
|
|
|
|
{
|
|
|
|
S390CPUClass *scc = S390_CPU_CLASS(oc);
|
|
|
|
CPUClass *cc = CPU_CLASS(scc);
|
2013-01-20 22:41:06 +04:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(oc);
|
2012-04-02 13:39:23 +04:00
|
|
|
|
2018-01-14 05:04:12 +03:00
|
|
|
device_class_set_parent_realize(dc, s390_cpu_realizefn,
|
|
|
|
&scc->parent_realize);
|
2020-01-10 18:30:32 +03:00
|
|
|
device_class_set_props(dc, s390x_cpu_properties);
|
2017-09-13 16:24:11 +03:00
|
|
|
dc->user_creatable = true;
|
2013-01-16 07:00:41 +04:00
|
|
|
|
cpu: Use DeviceClass reset instead of a special CPUClass reset
The CPUClass has a 'reset' method. This is a legacy from when
TYPE_CPU used not to inherit from TYPE_DEVICE. We don't need it any
more, as we can simply use the TYPE_DEVICE reset. The 'cpu_reset()'
function is kept as the API which most places use to reset a CPU; it
is now a wrapper which calls device_cold_reset() and then the
tracepoint function.
This change should not cause CPU objects to be reset more often
than they are at the moment, because:
* nobody is directly calling device_cold_reset() or
qdev_reset_all() on CPU objects
* no CPU object is on a qbus, so they will not be reset either
by somebody calling qbus_reset_all()/bus_cold_reset(), or
by the main "reset sysbus and everything in the qbus tree"
reset that most devices are reset by
Note that this does not change the need for each machine or whatever
to use qemu_register_reset() to arrange to call cpu_reset() -- that
is necessary because CPU objects are not on any qbus, so they don't
get reset when the qbus tree rooted at the sysbus bus is reset, and
this isn't being changed here.
All the changes to the files under target/ were made using the
included Coccinelle script, except:
(1) the deletion of the now-inaccurate and not terribly useful
"CPUClass::reset" comments was done with a perl one-liner afterwards:
perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c
(2) this bit of the s390 change was done by hand, because the
Coccinelle script is not sophisticated enough to handle the
parent_reset call being inside another function:
| @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
| S390CPU *cpu = S390_CPU(s);
| S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
| CPUS390XState *env = &cpu->env;
|+ DeviceState *dev = DEVICE(s);
|
|- scc->parent_reset(s);
|+ scc->parent_reset(dev);
| cpu->env.sigp_order = 0;
| s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-03 13:05:11 +03:00
|
|
|
device_class_set_parent_reset(dc, s390_cpu_reset_full, &scc->parent_reset);
|
2013-07-25 18:45:51 +04:00
|
|
|
#if !defined(CONFIG_USER_ONLY)
|
|
|
|
scc->load_normal = s390_cpu_load_normal;
|
|
|
|
#endif
|
2019-11-27 20:50:42 +03:00
|
|
|
scc->reset = s390_cpu_reset;
|
2016-09-05 11:52:16 +03:00
|
|
|
cc->class_by_name = s390_cpu_class_by_name,
|
2013-08-25 20:53:55 +04:00
|
|
|
cc->has_work = s390_cpu_has_work;
|
2017-07-24 11:52:50 +03:00
|
|
|
#ifdef CONFIG_TCG
|
2013-02-02 13:57:51 +04:00
|
|
|
cc->do_interrupt = s390_cpu_do_interrupt;
|
2017-07-24 11:52:50 +03:00
|
|
|
#endif
|
2013-05-27 03:33:50 +04:00
|
|
|
cc->dump_state = s390_cpu_dump_state;
|
2013-06-21 21:09:18 +04:00
|
|
|
cc->set_pc = s390_cpu_set_pc;
|
2013-06-29 06:18:45 +04:00
|
|
|
cc->gdb_read_register = s390_cpu_gdb_read_register;
|
|
|
|
cc->gdb_write_register = s390_cpu_gdb_write_register;
|
2019-04-02 14:02:09 +03:00
|
|
|
#ifndef CONFIG_USER_ONLY
|
2013-06-29 20:55:54 +04:00
|
|
|
cc->get_phys_page_debug = s390_cpu_get_phys_page_debug;
|
2014-09-30 12:58:42 +04:00
|
|
|
cc->vmsd = &vmstate_s390_cpu;
|
2020-05-22 20:25:08 +03:00
|
|
|
cc->get_crash_info = s390_cpu_get_crash_info;
|
2013-07-10 17:26:46 +04:00
|
|
|
cc->write_elf64_note = s390_cpu_write_elf64_note;
|
2017-07-24 11:52:50 +03:00
|
|
|
#ifdef CONFIG_TCG
|
2014-09-13 20:45:19 +04:00
|
|
|
cc->cpu_exec_interrupt = s390_cpu_exec_interrupt;
|
2015-06-13 01:46:00 +03:00
|
|
|
cc->debug_excp_handler = s390x_cpu_debug_excp_handler;
|
2017-03-02 05:06:18 +03:00
|
|
|
cc->do_unaligned_access = s390x_cpu_do_unaligned_access;
|
2017-07-24 11:52:50 +03:00
|
|
|
#endif
|
2013-06-29 20:55:54 +04:00
|
|
|
#endif
|
2015-07-12 04:59:58 +03:00
|
|
|
cc->disas_set_info = s390_cpu_disas_set_info;
|
2017-10-26 16:58:14 +03:00
|
|
|
#ifdef CONFIG_TCG
|
2017-10-16 05:02:42 +03:00
|
|
|
cc->tcg_initialize = s390x_translate_init;
|
2019-04-02 14:02:09 +03:00
|
|
|
cc->tlb_fill = s390_cpu_tlb_fill;
|
2017-10-26 16:58:14 +03:00
|
|
|
#endif
|
2015-07-12 04:59:58 +03:00
|
|
|
|
2014-08-29 17:52:16 +04:00
|
|
|
cc->gdb_num_core_regs = S390_NUM_CORE_REGS;
|
|
|
|
cc->gdb_core_xml_file = "s390x-core64.xml";
|
2015-12-03 15:14:41 +03:00
|
|
|
cc->gdb_arch_name = s390_gdb_arch_name;
|
qdev: Protect device-list-properties against broken devices
Several devices don't survive object_unref(object_new(T)): they crash
or hang during cleanup, or they leave dangling pointers behind.
This breaks at least device-list-properties, because
qmp_device_list_properties() needs to create a device to find its
properties. Broken in commit f4eb32b "qmp: show QOM properties in
device-list-properties", v2.1. Example reproducer:
$ qemu-system-aarch64 -nodefaults -display none -machine none -S -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2}, "package": ""}, "capabilities": []}}
{ "execute": "qmp_capabilities" }
{"return": {}}
{ "execute": "device-list-properties", "arguments": { "typename": "pxa2xx-pcmcia" } }
qemu-system-aarch64: /home/armbru/work/qemu/memory.c:1307: memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void *)0))' failed.
Aborted (core dumped)
[Exit 134 (SIGABRT)]
Unfortunately, I can't fix the problems in these devices right now.
Instead, add DeviceClass member cannot_destroy_with_object_finalize_yet
to mark them:
* Hang during cleanup (didn't debug, so I can't say why):
"realview_pci", "versatile_pci".
* Dangling pointer in cpus: most CPUs, plus "allwinner-a10", "digic",
"fsl,imx25", "fsl,imx31", "xlnx,zynqmp", because they create such
CPUs
* Assert kvm_enabled(): "host-x86_64-cpu", host-i386-cpu",
"host-powerpc64-cpu", "host-embedded-powerpc-cpu",
"host-powerpc-cpu" (the powerpc ones can't currently reach the
assertion, because the CPUs are only registered when KVM is enabled,
but the assertion is arguably in the wrong place all the same)
Make qmp_device_list_properties() fail cleanly when the device is so
marked. This improves device-list-properties from "crashes, hangs or
leaves dangling pointers behind" to "fails". Not a complete fix, just
a better-than-nothing work-around. In the above reproducer,
device-list-properties now fails with "Can't list properties of device
'pxa2xx-pcmcia'".
This also protects -device FOO,help, which uses the same machinery
since commit ef52358 "qdev-monitor: include QOM properties in -device
FOO, help output", v2.2. Example reproducer:
$ qemu-system-aarch64 -machine none -device pxa2xx-pcmcia,help
Before:
qemu-system-aarch64: .../memory.c:1307: memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void *)0))' failed.
After:
Can't list properties of device 'pxa2xx-pcmcia'
Cc: "Andreas Färber" <afaerber@suse.de>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Anthony Green <green@moxielogic.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Cc: Blue Swirl <blauwirbel@gmail.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Jia Liu <proljc@gmail.com>
Cc: Leon Alrae <leon.alrae@imgtec.com>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: qemu-ppc@nongnu.org
Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <1443689999-12182-10-git-send-email-armbru@redhat.com>
2015-10-01 11:59:58 +03:00
|
|
|
|
2016-09-05 11:52:17 +03:00
|
|
|
s390_cpu_model_class_register_props(oc);
|
2012-04-02 13:39:23 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo s390_cpu_type_info = {
|
|
|
|
.name = TYPE_S390_CPU,
|
|
|
|
.parent = TYPE_CPU,
|
|
|
|
.instance_size = sizeof(S390CPU),
|
2020-09-16 03:46:38 +03:00
|
|
|
.instance_align = __alignof__(S390CPU),
|
2012-04-02 15:56:29 +04:00
|
|
|
.instance_init = s390_cpu_initfn,
|
2013-01-07 10:14:16 +04:00
|
|
|
.instance_finalize = s390_cpu_finalize,
|
2016-09-05 11:52:16 +03:00
|
|
|
.abstract = true,
|
2012-04-02 13:39:23 +04:00
|
|
|
.class_size = sizeof(S390CPUClass),
|
|
|
|
.class_init = s390_cpu_class_init,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void s390_cpu_register_types(void)
|
|
|
|
{
|
|
|
|
type_register_static(&s390_cpu_type_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
type_init(s390_cpu_register_types)
|