2012-10-29 06:13:22 +04:00
|
|
|
/*
|
|
|
|
* SCLP Support
|
|
|
|
*
|
|
|
|
* Copyright IBM, Corp. 2012
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Christian Borntraeger <borntraeger@de.ibm.com>
|
|
|
|
* Heinz Graalfs <graalfs@linux.vnet.ibm.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or (at your
|
|
|
|
* option) any later version. See the COPYING file in the top-level directory.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2016-01-26 21:17:00 +03:00
|
|
|
#include "qemu/osdep.h"
|
2018-06-25 15:42:11 +03:00
|
|
|
#include "qemu/units.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"
|
2015-05-29 14:14:50 +03:00
|
|
|
#include "hw/boards.h"
|
2013-02-04 18:40:22 +04:00
|
|
|
#include "hw/s390x/sclp.h"
|
2013-12-18 13:10:49 +04:00
|
|
|
#include "hw/s390x/event-facility.h"
|
2015-01-09 11:04:38 +03:00
|
|
|
#include "hw/s390x/s390-pci-bus.h"
|
2016-03-29 17:34:37 +03:00
|
|
|
#include "hw/s390x/ipl.h"
|
2023-10-16 21:39:09 +03:00
|
|
|
#include "hw/s390x/cpu-topology.h"
|
2024-05-02 16:15:33 +03:00
|
|
|
#include "hw/s390x/s390-virtio-ccw.h"
|
2012-10-29 06:13:22 +04:00
|
|
|
|
2024-05-02 16:15:33 +03:00
|
|
|
static SCLPDevice *get_sclp_device(void)
|
2015-05-27 11:04:56 +03:00
|
|
|
{
|
2016-08-10 13:14:19 +03:00
|
|
|
static SCLPDevice *sclp;
|
|
|
|
|
|
|
|
if (!sclp) {
|
2024-05-02 16:15:33 +03:00
|
|
|
sclp = S390_CCW_MACHINE(qdev_get_machine())->sclp;
|
2016-08-10 13:14:19 +03:00
|
|
|
}
|
|
|
|
return sclp;
|
2015-05-27 11:04:56 +03:00
|
|
|
}
|
|
|
|
|
2020-03-19 16:19:14 +03:00
|
|
|
static inline bool sclp_command_code_valid(uint32_t code)
|
|
|
|
{
|
|
|
|
switch (code & SCLP_CMD_CODE_MASK) {
|
|
|
|
case SCLP_CMDW_READ_SCP_INFO:
|
|
|
|
case SCLP_CMDW_READ_SCP_INFO_FORCED:
|
|
|
|
case SCLP_CMDW_READ_CPU_INFO:
|
|
|
|
case SCLP_CMDW_CONFIGURE_IOA:
|
|
|
|
case SCLP_CMDW_DECONFIGURE_IOA:
|
|
|
|
case SCLP_CMD_READ_EVENT_DATA:
|
|
|
|
case SCLP_CMD_WRITE_EVENT_DATA:
|
|
|
|
case SCLP_CMD_WRITE_EVENT_MASK:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.
With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.
The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.
This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.
When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.
In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.
Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-09-15 22:44:14 +03:00
|
|
|
static bool sccb_verify_boundary(uint64_t sccb_addr, uint16_t sccb_len,
|
|
|
|
uint32_t code)
|
2020-09-15 22:44:10 +03:00
|
|
|
{
|
|
|
|
uint64_t sccb_max_addr = sccb_addr + sccb_len - 1;
|
2021-09-01 15:58:00 +03:00
|
|
|
uint64_t sccb_boundary = (sccb_addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE;
|
2020-09-15 22:44:10 +03:00
|
|
|
|
s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.
With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.
The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.
This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.
When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.
In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.
Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-09-15 22:44:14 +03:00
|
|
|
switch (code & SCLP_CMD_CODE_MASK) {
|
|
|
|
case SCLP_CMDW_READ_SCP_INFO:
|
|
|
|
case SCLP_CMDW_READ_SCP_INFO_FORCED:
|
|
|
|
case SCLP_CMDW_READ_CPU_INFO:
|
|
|
|
/*
|
|
|
|
* An extended-length SCCB is only allowed for Read SCP/CPU Info and
|
|
|
|
* is allowed to exceed the 4k boundary. The respective commands will
|
|
|
|
* set the length field to the required length if an insufficient
|
|
|
|
* SCCB length is provided.
|
|
|
|
*/
|
|
|
|
if (s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
/* fallthrough */
|
|
|
|
default:
|
|
|
|
if (sccb_max_addr < sccb_boundary) {
|
|
|
|
return true;
|
|
|
|
}
|
2020-09-15 22:44:10 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-09-15 22:44:09 +03:00
|
|
|
static void prepare_cpu_entries(MachineState *ms, CPUEntry *entry, int *count)
|
2016-09-05 11:52:27 +03:00
|
|
|
{
|
2016-09-05 11:52:29 +03:00
|
|
|
uint8_t features[SCCB_CPU_FEATURE_LEN] = { 0 };
|
2016-09-05 11:52:27 +03:00
|
|
|
int i;
|
|
|
|
|
2016-09-05 11:52:29 +03:00
|
|
|
s390_get_feat_block(S390_FEAT_TYPE_SCLP_CPU, features);
|
2017-09-13 16:24:16 +03:00
|
|
|
for (i = 0, *count = 0; i < ms->possible_cpus->len; i++) {
|
|
|
|
if (!ms->possible_cpus->cpus[i].cpu) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
entry[*count].address = ms->possible_cpus->cpus[i].arch_id;
|
|
|
|
entry[*count].type = 0;
|
|
|
|
memcpy(entry[*count].features, features, sizeof(features));
|
|
|
|
(*count)++;
|
2016-09-05 11:52:27 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-15 22:44:12 +03:00
|
|
|
#define SCCB_REQ_LEN(s, max_cpus) (sizeof(s) + max_cpus * sizeof(CPUEntry))
|
|
|
|
|
s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.
With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.
The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.
This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.
When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.
In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.
Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-09-15 22:44:14 +03:00
|
|
|
static inline bool ext_len_sccb_supported(SCCBHeader header)
|
|
|
|
{
|
|
|
|
return s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB) &&
|
|
|
|
header.control_mask[2] & SCLP_VARIABLE_LENGTH_RESPONSE;
|
|
|
|
}
|
|
|
|
|
2012-10-29 06:13:22 +04:00
|
|
|
/* Provide information about the configuration, CPUs and storage */
|
2015-05-27 11:04:56 +03:00
|
|
|
static void read_SCP_info(SCLPDevice *sclp, SCCB *sccb)
|
2012-10-29 06:13:22 +04:00
|
|
|
{
|
|
|
|
ReadInfo *read_info = (ReadInfo *) sccb;
|
2015-05-29 14:14:50 +03:00
|
|
|
MachineState *machine = MACHINE(qdev_get_machine());
|
2017-09-13 16:24:16 +03:00
|
|
|
int cpu_count;
|
2014-08-28 19:25:35 +04:00
|
|
|
int rnsize, rnmax;
|
2016-03-29 17:34:37 +03:00
|
|
|
IplParameterBlock *ipib = s390_ipl_get_iplb();
|
2020-09-15 22:44:12 +03:00
|
|
|
int required_len = SCCB_REQ_LEN(ReadInfo, machine->possible_cpus->len);
|
s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.
With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.
The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.
This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.
When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.
In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.
Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-09-15 22:44:14 +03:00
|
|
|
int offset_cpu = s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB) ?
|
|
|
|
offsetof(ReadInfo, entries) :
|
|
|
|
SCLP_READ_SCP_INFO_FIXED_CPU_OFFSET;
|
2020-09-15 22:44:13 +03:00
|
|
|
CPUEntry *entries_start = (void *)sccb + offset_cpu;
|
2020-09-15 22:44:12 +03:00
|
|
|
|
|
|
|
if (be16_to_cpu(sccb->h.length) < required_len) {
|
s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.
With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.
The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.
This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.
When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.
In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.
Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-09-15 22:44:14 +03:00
|
|
|
if (ext_len_sccb_supported(sccb->h)) {
|
|
|
|
sccb->h.length = cpu_to_be16(required_len);
|
|
|
|
}
|
2020-09-15 22:44:12 +03:00
|
|
|
sccb->h.response_code = cpu_to_be16(SCLP_RC_INSUFFICIENT_SCCB_LENGTH);
|
|
|
|
return;
|
|
|
|
}
|
2014-01-20 23:51:49 +04:00
|
|
|
|
2023-10-16 21:39:09 +03:00
|
|
|
if (s390_has_topology()) {
|
|
|
|
read_info->stsi_parm = SCLP_READ_SCP_INFO_MNEST;
|
|
|
|
}
|
|
|
|
|
2014-01-20 23:51:49 +04:00
|
|
|
/* CPU information */
|
2020-09-15 22:44:13 +03:00
|
|
|
prepare_cpu_entries(machine, entries_start, &cpu_count);
|
2014-01-20 23:51:49 +04:00
|
|
|
read_info->entries_cpu = cpu_to_be16(cpu_count);
|
2020-09-15 22:44:13 +03:00
|
|
|
read_info->offset_cpu = cpu_to_be16(offset_cpu);
|
2019-05-18 23:54:24 +03:00
|
|
|
read_info->highest_cpu = cpu_to_be16(machine->smp.max_cpus - 1);
|
2014-01-20 23:51:49 +04:00
|
|
|
|
2016-09-05 11:52:30 +03:00
|
|
|
read_info->ibc_val = cpu_to_be32(s390_get_ibc_val());
|
|
|
|
|
2016-09-05 11:52:29 +03:00
|
|
|
/* Configuration Characteristic (Extension) */
|
|
|
|
s390_get_feat_block(S390_FEAT_TYPE_SCLP_CONF_CHAR,
|
|
|
|
read_info->conf_char);
|
|
|
|
s390_get_feat_block(S390_FEAT_TYPE_SCLP_CONF_CHAR_EXT,
|
|
|
|
read_info->conf_char_ext);
|
|
|
|
|
2020-09-15 22:44:16 +03:00
|
|
|
if (s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB)) {
|
|
|
|
s390_get_feat_block(S390_FEAT_TYPE_SCLP_FAC134,
|
|
|
|
&read_info->fac134);
|
|
|
|
}
|
|
|
|
|
2015-01-09 11:04:38 +03:00
|
|
|
read_info->facilities = cpu_to_be64(SCLP_HAS_CPU_INFO |
|
2017-07-06 18:13:14 +03:00
|
|
|
SCLP_HAS_IOA_RECONFIG);
|
2012-10-29 06:13:22 +04:00
|
|
|
|
2016-09-05 11:52:31 +03:00
|
|
|
read_info->mha_pow = s390_get_mha_pow();
|
2016-09-05 11:52:32 +03:00
|
|
|
read_info->hmfai = cpu_to_be32(s390_get_hmfai());
|
2014-08-28 19:25:35 +04:00
|
|
|
|
2015-06-01 14:03:23 +03:00
|
|
|
rnsize = 1 << (sclp->increment_size - 20);
|
2014-08-28 19:25:35 +04:00
|
|
|
if (rnsize <= 128) {
|
|
|
|
read_info->rnsize = rnsize;
|
|
|
|
} else {
|
|
|
|
read_info->rnsize = 0;
|
|
|
|
read_info->rnsize2 = cpu_to_be32(rnsize);
|
|
|
|
}
|
|
|
|
|
s390x/sclp: remove memory hotplug support
From an architecture point of view, nothing can be mapped into the address
space on s390x. All there is is memory. Therefore there is also not really
an interface to communicate such information to the guest. All we can do is
specify the maximum ram address and guests can probe in that range if
memory is available and usable (TPROT).
Also memory hotplug is strange. The guest can decide at some point in
time to add / remove memory in some range. While the hypervisor can deny
to online an increment, all increments have to be predefined and there is
no way of telling the guest about a newly "hotplugged" increment. So if we
specify right now e.g.
-m 2G,slots=2,maxmem=20G
An ordinary fedora guest will happily online (hotplug) all memory,
resulting in a guest consuming 20G. So it really behaves rather like
-m 22G
There is no way to hotplug memory from the outside like on other
architectures. This is of course bad for upper management layers.
As the guest can create/delete memory regions while it is running, of
course migration support is not available and tricky to implement.
With virtualization, it is different. We might want to map something
into guest address space (e.g. fake DAX devices) and not detect it
automatically as memory. So we really want to use the maxmem and slots
parameter just like on all other architectures. Such devices will have
to expose the applicable memory range themselves. To finally be able to
provide memory hotplug to guests, we will need a new paravirtualized
interface to do that (e.g. something into the direction of virtio-mem).
This implies, that maxmem cannot be used for s390x memory hotplug
anymore and has to go. This simplifies the code quite a bit.
As migration support is not working, this change cannot really break
migration as guests without slots and maxmem don't see the SCLP
features. Also, the ram size calculation does not change.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20180219174231.10874-1-david@redhat.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
[CH: tweaked patch description, as discussed on list]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-19 20:42:31 +03:00
|
|
|
/* we don't support standby memory, maxram_size is never exposed */
|
|
|
|
rnmax = machine->ram_size >> sclp->increment_size;
|
2014-08-28 19:25:35 +04:00
|
|
|
if (rnmax < 0x10000) {
|
|
|
|
read_info->rnmax = cpu_to_be16(rnmax);
|
|
|
|
} else {
|
|
|
|
read_info->rnmax = cpu_to_be16(0);
|
|
|
|
read_info->rnmax2 = cpu_to_be64(rnmax);
|
|
|
|
}
|
|
|
|
|
2016-03-29 17:34:37 +03:00
|
|
|
if (ipib && ipib->flags & DIAG308_FLAGS_LP_VALID) {
|
|
|
|
memcpy(&read_info->loadparm, &ipib->loadparm,
|
|
|
|
sizeof(read_info->loadparm));
|
|
|
|
} else {
|
|
|
|
s390_ipl_set_loadparm(read_info->loadparm);
|
|
|
|
}
|
|
|
|
|
2014-08-28 19:25:35 +04:00
|
|
|
sccb->h.response_code = cpu_to_be16(SCLP_RC_NORMAL_READ_COMPLETION);
|
|
|
|
}
|
|
|
|
|
2014-01-20 23:51:49 +04:00
|
|
|
/* Provide information about the CPU */
|
2015-05-27 11:04:56 +03:00
|
|
|
static void sclp_read_cpu_info(SCLPDevice *sclp, SCCB *sccb)
|
2014-01-20 23:51:49 +04:00
|
|
|
{
|
2020-09-15 22:44:09 +03:00
|
|
|
MachineState *machine = MACHINE(qdev_get_machine());
|
2014-01-20 23:51:49 +04:00
|
|
|
ReadCpuInfo *cpu_info = (ReadCpuInfo *) sccb;
|
2017-09-13 16:24:16 +03:00
|
|
|
int cpu_count;
|
2020-09-15 22:44:12 +03:00
|
|
|
int required_len = SCCB_REQ_LEN(ReadCpuInfo, machine->possible_cpus->len);
|
|
|
|
|
|
|
|
if (be16_to_cpu(sccb->h.length) < required_len) {
|
s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.
With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.
The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.
This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.
When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.
In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.
Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-09-15 22:44:14 +03:00
|
|
|
if (ext_len_sccb_supported(sccb->h)) {
|
|
|
|
sccb->h.length = cpu_to_be16(required_len);
|
|
|
|
}
|
2020-09-15 22:44:12 +03:00
|
|
|
sccb->h.response_code = cpu_to_be16(SCLP_RC_INSUFFICIENT_SCCB_LENGTH);
|
|
|
|
return;
|
|
|
|
}
|
2014-01-20 23:51:49 +04:00
|
|
|
|
2020-09-15 22:44:09 +03:00
|
|
|
prepare_cpu_entries(machine, cpu_info->entries, &cpu_count);
|
2014-01-20 23:51:49 +04:00
|
|
|
cpu_info->nr_configured = cpu_to_be16(cpu_count);
|
|
|
|
cpu_info->offset_configured = cpu_to_be16(offsetof(ReadCpuInfo, entries));
|
|
|
|
cpu_info->nr_standby = cpu_to_be16(0);
|
|
|
|
|
|
|
|
/* The standby offset is 16-byte for each CPU */
|
|
|
|
cpu_info->offset_standby = cpu_to_be16(cpu_info->offset_configured
|
|
|
|
+ cpu_info->nr_configured*sizeof(CPUEntry));
|
|
|
|
|
|
|
|
|
|
|
|
sccb->h.response_code = cpu_to_be16(SCLP_RC_NORMAL_READ_COMPLETION);
|
|
|
|
}
|
|
|
|
|
2017-07-06 18:13:14 +03:00
|
|
|
static void sclp_configure_io_adapter(SCLPDevice *sclp, SCCB *sccb,
|
|
|
|
bool configure)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (be16_to_cpu(sccb->h.length) < 16) {
|
|
|
|
rc = SCLP_RC_INSUFFICIENT_SCCB_LENGTH;
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (((IoaCfgSccb *)sccb)->atype) {
|
|
|
|
case SCLP_RECONFIG_PCI_ATYPE:
|
|
|
|
if (s390_has_feat(S390_FEAT_ZPCI)) {
|
|
|
|
if (configure) {
|
|
|
|
s390_pci_sclp_configure(sccb);
|
|
|
|
} else {
|
|
|
|
s390_pci_sclp_deconfigure(sccb);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* fallthrough */
|
|
|
|
default:
|
|
|
|
rc = SCLP_RC_ADAPTER_TYPE_NOT_RECOGNIZED;
|
|
|
|
}
|
|
|
|
|
|
|
|
out_err:
|
|
|
|
sccb->h.response_code = cpu_to_be16(rc);
|
|
|
|
}
|
|
|
|
|
2015-05-27 11:04:56 +03:00
|
|
|
static void sclp_execute(SCLPDevice *sclp, SCCB *sccb, uint32_t code)
|
2012-10-29 06:13:22 +04:00
|
|
|
{
|
2015-05-27 11:04:56 +03:00
|
|
|
SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
|
|
|
|
SCLPEventFacility *ef = sclp->event_facility;
|
2013-12-18 13:10:49 +04:00
|
|
|
SCLPEventFacilityClass *efc = EVENT_FACILITY_GET_CLASS(ef);
|
2012-10-29 06:13:23 +04:00
|
|
|
|
2014-01-20 23:51:48 +04:00
|
|
|
switch (code & SCLP_CMD_CODE_MASK) {
|
2012-10-29 06:13:22 +04:00
|
|
|
case SCLP_CMDW_READ_SCP_INFO:
|
|
|
|
case SCLP_CMDW_READ_SCP_INFO_FORCED:
|
2015-05-27 11:04:56 +03:00
|
|
|
sclp_c->read_SCP_info(sclp, sccb);
|
2012-10-29 06:13:22 +04:00
|
|
|
break;
|
2014-01-20 23:51:49 +04:00
|
|
|
case SCLP_CMDW_READ_CPU_INFO:
|
2015-05-27 11:04:56 +03:00
|
|
|
sclp_c->read_cpu_info(sclp, sccb);
|
2014-01-20 23:51:49 +04:00
|
|
|
break;
|
2017-07-06 18:13:14 +03:00
|
|
|
case SCLP_CMDW_CONFIGURE_IOA:
|
|
|
|
sclp_configure_io_adapter(sclp, sccb, true);
|
2015-01-09 11:04:38 +03:00
|
|
|
break;
|
2017-07-06 18:13:14 +03:00
|
|
|
case SCLP_CMDW_DECONFIGURE_IOA:
|
|
|
|
sclp_configure_io_adapter(sclp, sccb, false);
|
2015-01-09 11:04:38 +03:00
|
|
|
break;
|
2012-10-29 06:13:22 +04:00
|
|
|
default:
|
2013-12-18 13:10:49 +04:00
|
|
|
efc->command_handler(ef, sccb, code);
|
2012-10-29 06:13:22 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-19 16:19:14 +03:00
|
|
|
/*
|
|
|
|
* We only need the address to have something valid for the
|
|
|
|
* service_interrupt call.
|
|
|
|
*/
|
|
|
|
#define SCLP_PV_DUMMY_ADDR 0x4000
|
2023-11-06 09:55:22 +03:00
|
|
|
int sclp_service_call_protected(S390CPU *cpu, uint64_t sccb, uint32_t code)
|
2020-03-19 16:19:14 +03:00
|
|
|
{
|
2023-11-06 09:55:22 +03:00
|
|
|
CPUS390XState *env = &cpu->env;
|
2020-03-19 16:19:14 +03:00
|
|
|
SCLPDevice *sclp = get_sclp_device();
|
|
|
|
SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
|
2020-09-15 22:44:11 +03:00
|
|
|
SCCBHeader header;
|
|
|
|
g_autofree SCCB *work_sccb = NULL;
|
2020-03-19 16:19:14 +03:00
|
|
|
|
2020-09-15 22:44:11 +03:00
|
|
|
s390_cpu_pv_mem_read(env_archcpu(env), 0, &header, sizeof(SCCBHeader));
|
|
|
|
|
|
|
|
work_sccb = g_malloc0(be16_to_cpu(header.length));
|
|
|
|
s390_cpu_pv_mem_read(env_archcpu(env), 0, work_sccb,
|
|
|
|
be16_to_cpu(header.length));
|
2020-03-19 16:19:14 +03:00
|
|
|
|
|
|
|
if (!sclp_command_code_valid(code)) {
|
2020-09-15 22:44:11 +03:00
|
|
|
work_sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
|
2020-03-19 16:19:14 +03:00
|
|
|
goto out_write;
|
|
|
|
}
|
|
|
|
|
2020-09-15 22:44:11 +03:00
|
|
|
sclp_c->execute(sclp, work_sccb, code);
|
2020-03-19 16:19:14 +03:00
|
|
|
out_write:
|
2020-09-15 22:44:11 +03:00
|
|
|
s390_cpu_pv_mem_write(env_archcpu(env), 0, work_sccb,
|
|
|
|
be16_to_cpu(work_sccb->h.length));
|
2020-03-19 16:19:14 +03:00
|
|
|
sclp_c->service_interrupt(sclp, SCLP_PV_DUMMY_ADDR);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-11-06 09:55:22 +03:00
|
|
|
int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code)
|
2012-10-29 06:13:22 +04:00
|
|
|
{
|
2023-11-06 09:55:22 +03:00
|
|
|
CPUS390XState *env = &cpu->env;
|
2015-05-27 11:04:56 +03:00
|
|
|
SCLPDevice *sclp = get_sclp_device();
|
|
|
|
SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
|
2020-09-15 22:44:11 +03:00
|
|
|
SCCBHeader header;
|
|
|
|
g_autofree SCCB *work_sccb = NULL;
|
2012-10-29 06:13:22 +04:00
|
|
|
|
|
|
|
/* first some basic checks on program checks */
|
2014-01-13 15:55:55 +04:00
|
|
|
if (env->psw.mask & PSW_MASK_PSTATE) {
|
2020-01-06 21:24:04 +03:00
|
|
|
return -PGM_PRIVILEGED;
|
2014-01-13 15:55:55 +04:00
|
|
|
}
|
2012-10-29 06:13:22 +04:00
|
|
|
if (cpu_physical_memory_is_io(sccb)) {
|
2020-01-06 21:24:04 +03:00
|
|
|
return -PGM_ADDRESSING;
|
2012-10-29 06:13:22 +04:00
|
|
|
}
|
2014-01-13 15:55:55 +04:00
|
|
|
if ((sccb & ~0x1fffUL) == 0 || (sccb & ~0x1fffUL) == env->psa
|
|
|
|
|| (sccb & ~0x7ffffff8UL) != 0) {
|
2020-01-06 21:24:04 +03:00
|
|
|
return -PGM_SPECIFICATION;
|
2012-10-29 06:13:22 +04:00
|
|
|
}
|
|
|
|
|
2020-09-15 22:44:11 +03:00
|
|
|
/* the header contains the actual length of the sccb */
|
|
|
|
cpu_physical_memory_read(sccb, &header, sizeof(SCCBHeader));
|
|
|
|
|
|
|
|
/* Valid sccb sizes */
|
|
|
|
if (be16_to_cpu(header.length) < sizeof(SCCBHeader)) {
|
|
|
|
return -PGM_SPECIFICATION;
|
|
|
|
}
|
|
|
|
|
2012-10-29 06:13:22 +04:00
|
|
|
/*
|
|
|
|
* we want to work on a private copy of the sccb, to prevent guests
|
|
|
|
* from playing dirty tricks by modifying the memory content after
|
|
|
|
* the host has checked the values
|
|
|
|
*/
|
2020-09-15 22:44:11 +03:00
|
|
|
work_sccb = g_malloc0(be16_to_cpu(header.length));
|
|
|
|
cpu_physical_memory_read(sccb, work_sccb, be16_to_cpu(header.length));
|
2012-10-29 06:13:22 +04:00
|
|
|
|
2020-03-19 16:19:14 +03:00
|
|
|
if (!sclp_command_code_valid(code)) {
|
2020-09-15 22:44:11 +03:00
|
|
|
work_sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
|
2019-09-27 16:33:20 +03:00
|
|
|
goto out_write;
|
|
|
|
}
|
2012-10-29 06:13:22 +04:00
|
|
|
|
s390/sclp: add extended-length sccb support for kvm guest
As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.
With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.
The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.
This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.
When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.
In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.
Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-09-15 22:44:14 +03:00
|
|
|
if (!sccb_verify_boundary(sccb, be16_to_cpu(work_sccb->h.length), code)) {
|
2020-09-15 22:44:11 +03:00
|
|
|
work_sccb->h.response_code = cpu_to_be16(SCLP_RC_SCCB_BOUNDARY_VIOLATION);
|
2019-09-27 16:33:21 +03:00
|
|
|
goto out_write;
|
|
|
|
}
|
|
|
|
|
2020-09-15 22:44:11 +03:00
|
|
|
sclp_c->execute(sclp, work_sccb, code);
|
2019-09-27 16:33:20 +03:00
|
|
|
out_write:
|
2020-09-15 22:44:11 +03:00
|
|
|
cpu_physical_memory_write(sccb, work_sccb,
|
|
|
|
be16_to_cpu(work_sccb->h.length));
|
2012-10-29 06:13:22 +04:00
|
|
|
|
2015-05-13 16:06:44 +03:00
|
|
|
sclp_c->service_interrupt(sclp, sccb);
|
2012-10-29 06:13:22 +04:00
|
|
|
|
2020-01-06 21:24:04 +03:00
|
|
|
return 0;
|
2012-10-29 06:13:22 +04:00
|
|
|
}
|
|
|
|
|
2015-05-13 16:06:44 +03:00
|
|
|
static void service_interrupt(SCLPDevice *sclp, uint32_t sccb)
|
2012-10-29 06:13:22 +04:00
|
|
|
{
|
2015-05-13 16:06:44 +03:00
|
|
|
SCLPEventFacility *ef = sclp->event_facility;
|
2013-12-18 13:10:49 +04:00
|
|
|
SCLPEventFacilityClass *efc = EVENT_FACILITY_GET_CLASS(ef);
|
|
|
|
|
2012-10-29 06:13:23 +04:00
|
|
|
uint32_t param = sccb & ~3;
|
|
|
|
|
|
|
|
/* Indicate whether an event is still pending */
|
2013-12-18 13:10:49 +04:00
|
|
|
param |= efc->event_pending(ef) ? 1 : 0;
|
2012-10-29 06:13:23 +04:00
|
|
|
|
|
|
|
if (!param) {
|
|
|
|
/* No need to send an interrupt, there's nothing to be notified about */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
s390_sclp_extint(param);
|
2012-10-29 06:13:22 +04:00
|
|
|
}
|
|
|
|
|
2015-05-13 16:06:44 +03:00
|
|
|
void sclp_service_interrupt(uint32_t sccb)
|
|
|
|
{
|
|
|
|
SCLPDevice *sclp = get_sclp_device();
|
|
|
|
SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
|
|
|
|
|
|
|
|
sclp_c->service_interrupt(sclp, sccb);
|
|
|
|
}
|
|
|
|
|
2012-10-29 06:13:22 +04:00
|
|
|
/* qemu object creation and initialization functions */
|
2015-05-27 10:49:43 +03:00
|
|
|
static void sclp_realize(DeviceState *dev, Error **errp)
|
|
|
|
{
|
2015-05-29 14:53:08 +03:00
|
|
|
MachineState *machine = MACHINE(qdev_get_machine());
|
2015-05-27 10:49:43 +03:00
|
|
|
SCLPDevice *sclp = SCLP(dev);
|
2015-05-29 14:53:08 +03:00
|
|
|
uint64_t hw_limit;
|
|
|
|
int ret;
|
2015-05-27 10:49:43 +03:00
|
|
|
|
2015-11-23 15:03:08 +03:00
|
|
|
/*
|
|
|
|
* qdev_device_add searches the sysbus for TYPE_SCLP_EVENTS_BUS. As long
|
|
|
|
* as we can't find a fitting bus via the qom tree, we have to add the
|
|
|
|
* event facility to the sysbus, so e.g. a sclp console can be created.
|
|
|
|
*/
|
2020-07-07 19:06:04 +03:00
|
|
|
if (!sysbus_realize(SYS_BUS_DEVICE(sclp->event_facility), errp)) {
|
|
|
|
return;
|
2020-06-10 08:32:01 +03:00
|
|
|
}
|
2015-05-29 14:53:08 +03:00
|
|
|
|
|
|
|
ret = s390_set_memory_limit(machine->maxram_size, &hw_limit);
|
|
|
|
if (ret == -E2BIG) {
|
2020-07-07 19:06:04 +03:00
|
|
|
error_setg(errp, "host supports a maximum of %" PRIu64 " GB",
|
2018-06-25 15:42:11 +03:00
|
|
|
hw_limit / GiB);
|
2015-05-29 14:53:08 +03:00
|
|
|
} else if (ret) {
|
2020-07-07 19:06:04 +03:00
|
|
|
error_setg(errp, "setting the guest size failed");
|
2015-05-29 14:53:08 +03:00
|
|
|
}
|
2015-05-27 10:49:43 +03:00
|
|
|
}
|
|
|
|
|
2015-05-29 14:53:08 +03:00
|
|
|
static void sclp_memory_init(SCLPDevice *sclp)
|
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(qdev_get_machine());
|
2020-04-01 15:37:54 +03:00
|
|
|
MachineClass *machine_class = MACHINE_GET_CLASS(qdev_get_machine());
|
2015-05-29 14:53:08 +03:00
|
|
|
ram_addr_t initial_mem = machine->ram_size;
|
|
|
|
int increment_size = 20;
|
|
|
|
|
|
|
|
/* The storage increment size is a multiple of 1M and is a power of 2.
|
2020-04-01 15:37:54 +03:00
|
|
|
* For some machine types, the number of storage increments must be
|
|
|
|
* MAX_STORAGE_INCREMENTS or fewer.
|
2015-05-29 14:53:08 +03:00
|
|
|
* The variable 'increment_size' is an exponent of 2 that can be
|
|
|
|
* used to calculate the size (in bytes) of an increment. */
|
2020-04-01 15:37:54 +03:00
|
|
|
while (machine_class->fixup_ram_size != NULL &&
|
|
|
|
(initial_mem >> increment_size) > MAX_STORAGE_INCREMENTS) {
|
2015-05-29 14:53:08 +03:00
|
|
|
increment_size++;
|
|
|
|
}
|
2015-06-01 14:03:23 +03:00
|
|
|
sclp->increment_size = increment_size;
|
2015-05-29 14:53:08 +03:00
|
|
|
}
|
|
|
|
|
2015-05-27 10:49:43 +03:00
|
|
|
static void sclp_init(Object *obj)
|
|
|
|
{
|
|
|
|
SCLPDevice *sclp = SCLP(obj);
|
|
|
|
Object *new;
|
|
|
|
|
|
|
|
new = object_new(TYPE_SCLP_EVENT_FACILITY);
|
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
|
|
|
object_property_add_child(obj, TYPE_SCLP_EVENT_FACILITY, new);
|
2015-05-27 10:49:43 +03:00
|
|
|
object_unref(new);
|
|
|
|
sclp->event_facility = EVENT_FACILITY(new);
|
2015-05-29 14:53:08 +03:00
|
|
|
|
|
|
|
sclp_memory_init(sclp);
|
2015-05-27 10:49:43 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void sclp_class_init(ObjectClass *oc, void *data)
|
|
|
|
{
|
2015-05-27 11:04:56 +03:00
|
|
|
SCLPDeviceClass *sc = SCLP_CLASS(oc);
|
2015-05-27 10:49:43 +03:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(oc);
|
|
|
|
|
|
|
|
dc->desc = "SCLP (Service-Call Logical Processor)";
|
|
|
|
dc->realize = sclp_realize;
|
|
|
|
dc->hotpluggable = false;
|
|
|
|
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
|
2017-10-04 16:53:19 +03:00
|
|
|
/*
|
|
|
|
* Reason: Creates TYPE_SCLP_EVENT_FACILITY in sclp_init
|
|
|
|
* which is a non-pluggable sysbus device
|
|
|
|
*/
|
|
|
|
dc->user_creatable = false;
|
2015-05-27 11:04:56 +03:00
|
|
|
|
|
|
|
sc->read_SCP_info = read_SCP_info;
|
|
|
|
sc->read_cpu_info = sclp_read_cpu_info;
|
|
|
|
sc->execute = sclp_execute;
|
2015-05-13 16:06:44 +03:00
|
|
|
sc->service_interrupt = service_interrupt;
|
2015-05-27 10:49:43 +03:00
|
|
|
}
|
|
|
|
|
2022-01-17 17:58:04 +03:00
|
|
|
static const TypeInfo sclp_info = {
|
2015-05-27 10:49:43 +03:00
|
|
|
.name = TYPE_SCLP,
|
|
|
|
.parent = TYPE_DEVICE,
|
|
|
|
.instance_init = sclp_init,
|
|
|
|
.instance_size = sizeof(SCLPDevice),
|
|
|
|
.class_init = sclp_class_init,
|
|
|
|
.class_size = sizeof(SCLPDeviceClass),
|
|
|
|
};
|
|
|
|
|
2014-08-28 19:25:32 +04:00
|
|
|
static void register_types(void)
|
|
|
|
{
|
2015-05-27 10:49:43 +03:00
|
|
|
type_register_static(&sclp_info);
|
2014-08-28 19:25:32 +04:00
|
|
|
}
|
|
|
|
type_init(register_types);
|