qemu-e2k/hw/s390x/sclp.c

477 lines
14 KiB
C
Raw Normal View History

/*
* 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.
*
*/
#include "qemu/osdep.h"
#include "qemu/units.h"
2016-03-14 09:01:28 +01:00
#include "qapi/error.h"
#include "hw/boards.h"
#include "hw/s390x/sclp.h"
s390x/event-facility: code restructure Code restructure in order to simplify class hierarchy - remove S390SCLPDevice abstract base class and move function pointers into new SCLPEventFacilityClass - implement SCLPEventFacility as SysBusDevice - use define constants for instance creation strings The following ascii-art shows the class structure wrt the SCLP EventFacility before (CURRENT) and after the restructure (NEW): ---- CURRENT: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacility | - to be replaced by new SCLPEventFacility, |-------------------------| which will be a SysBusDevice |SCLPEventsBus sbus | |DeviceState *qdev | |unsigned int receive_mask| +-------------------------+ +-------------------------+ | S390SCLPDeviceClass | - to be replaced by new SCLPEventFacilityClass |-------------------------| |DeviceClass qdev | |*(init)() | +-------------------------+ "s390-sclp-event-facility" | instance-of | V "s390-sclp-device" - this is an abstract class +-------------------------+ | S390SCLPDevice (A)| - to be replaced by new SCLPEventFacility |-------------------------| |SysBusDevice busdev | |SCLPEventFacility *ef | | | |*(sclp_command_handler)()| - these 2 go to new SCLPEventFacilityClass |*(event_pending)() | +-------------------------+ ---- NEW: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacilityClass | |-------------------------| |DeviceClass parent_class | | | |*(init)() | |*(command_handler)() | |*(event_pending)() | +-------------------------+ "s390-sclp-event-facility" +-------------------------+ | SCLPEventFacility | |-------------------------| |SysBusDevice parent_class| |SCLPEventsBus sbus | |unsigned int receive_mask| +-------------------------+ Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-12-18 10:10:49 +01:00
#include "hw/s390x/event-facility.h"
#include "hw/s390x/s390-pci-bus.h"
#include "hw/s390x/ipl.h"
static inline SCLPDevice *get_sclp_device(void)
{
static SCLPDevice *sclp;
if (!sclp) {
sclp = SCLP(object_resolve_path_type("", TYPE_SCLP, NULL));
}
return sclp;
}
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 21:44:14 +02:00
static bool sccb_verify_boundary(uint64_t sccb_addr, uint16_t sccb_len,
uint32_t code)
{
uint64_t sccb_max_addr = sccb_addr + sccb_len - 1;
uint64_t sccb_boundary = (sccb_addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE;
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 21:44:14 +02: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;
}
}
return false;
}
static void prepare_cpu_entries(MachineState *ms, CPUEntry *entry, int *count)
{
uint8_t features[SCCB_CPU_FEATURE_LEN] = { 0 };
int i;
s390_get_feat_block(S390_FEAT_TYPE_SCLP_CPU, features);
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)++;
}
}
#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 21:44:14 +02: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;
}
/* Provide information about the configuration, CPUs and storage */
static void read_SCP_info(SCLPDevice *sclp, SCCB *sccb)
{
ReadInfo *read_info = (ReadInfo *) sccb;
MachineState *machine = MACHINE(qdev_get_machine());
int cpu_count;
int rnsize, rnmax;
IplParameterBlock *ipib = s390_ipl_get_iplb();
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 21:44:14 +02:00
int offset_cpu = s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB) ?
offsetof(ReadInfo, entries) :
SCLP_READ_SCP_INFO_FIXED_CPU_OFFSET;
CPUEntry *entries_start = (void *)sccb + offset_cpu;
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 21:44:14 +02:00
if (ext_len_sccb_supported(sccb->h)) {
sccb->h.length = cpu_to_be16(required_len);
}
sccb->h.response_code = cpu_to_be16(SCLP_RC_INSUFFICIENT_SCCB_LENGTH);
return;
}
/* CPU information */
prepare_cpu_entries(machine, entries_start, &cpu_count);
read_info->entries_cpu = cpu_to_be16(cpu_count);
read_info->offset_cpu = cpu_to_be16(offset_cpu);
read_info->highest_cpu = cpu_to_be16(machine->smp.max_cpus - 1);
read_info->ibc_val = cpu_to_be32(s390_get_ibc_val());
/* 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);
if (s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB)) {
s390_get_feat_block(S390_FEAT_TYPE_SCLP_FAC134,
&read_info->fac134);
}
read_info->facilities = cpu_to_be64(SCLP_HAS_CPU_INFO |
SCLP_HAS_IOA_RECONFIG);
read_info->mha_pow = s390_get_mha_pow();
read_info->hmfai = cpu_to_be32(s390_get_hmfai());
rnsize = 1 << (sclp->increment_size - 20);
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 18:42:31 +01:00
/* we don't support standby memory, maxram_size is never exposed */
rnmax = machine->ram_size >> sclp->increment_size;
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);
}
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);
}
sccb->h.response_code = cpu_to_be16(SCLP_RC_NORMAL_READ_COMPLETION);
}
/* Provide information about the CPU */
static void sclp_read_cpu_info(SCLPDevice *sclp, SCCB *sccb)
{
MachineState *machine = MACHINE(qdev_get_machine());
ReadCpuInfo *cpu_info = (ReadCpuInfo *) sccb;
int cpu_count;
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 21:44:14 +02:00
if (ext_len_sccb_supported(sccb->h)) {
sccb->h.length = cpu_to_be16(required_len);
}
sccb->h.response_code = cpu_to_be16(SCLP_RC_INSUFFICIENT_SCCB_LENGTH);
return;
}
prepare_cpu_entries(machine, cpu_info->entries, &cpu_count);
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);
}
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);
}
static void sclp_execute(SCLPDevice *sclp, SCCB *sccb, uint32_t code)
{
SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
SCLPEventFacility *ef = sclp->event_facility;
s390x/event-facility: code restructure Code restructure in order to simplify class hierarchy - remove S390SCLPDevice abstract base class and move function pointers into new SCLPEventFacilityClass - implement SCLPEventFacility as SysBusDevice - use define constants for instance creation strings The following ascii-art shows the class structure wrt the SCLP EventFacility before (CURRENT) and after the restructure (NEW): ---- CURRENT: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacility | - to be replaced by new SCLPEventFacility, |-------------------------| which will be a SysBusDevice |SCLPEventsBus sbus | |DeviceState *qdev | |unsigned int receive_mask| +-------------------------+ +-------------------------+ | S390SCLPDeviceClass | - to be replaced by new SCLPEventFacilityClass |-------------------------| |DeviceClass qdev | |*(init)() | +-------------------------+ "s390-sclp-event-facility" | instance-of | V "s390-sclp-device" - this is an abstract class +-------------------------+ | S390SCLPDevice (A)| - to be replaced by new SCLPEventFacility |-------------------------| |SysBusDevice busdev | |SCLPEventFacility *ef | | | |*(sclp_command_handler)()| - these 2 go to new SCLPEventFacilityClass |*(event_pending)() | +-------------------------+ ---- NEW: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacilityClass | |-------------------------| |DeviceClass parent_class | | | |*(init)() | |*(command_handler)() | |*(event_pending)() | +-------------------------+ "s390-sclp-event-facility" +-------------------------+ | SCLPEventFacility | |-------------------------| |SysBusDevice parent_class| |SCLPEventsBus sbus | |unsigned int receive_mask| +-------------------------+ Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-12-18 10:10:49 +01:00
SCLPEventFacilityClass *efc = EVENT_FACILITY_GET_CLASS(ef);
switch (code & SCLP_CMD_CODE_MASK) {
case SCLP_CMDW_READ_SCP_INFO:
case SCLP_CMDW_READ_SCP_INFO_FORCED:
sclp_c->read_SCP_info(sclp, sccb);
break;
case SCLP_CMDW_READ_CPU_INFO:
sclp_c->read_cpu_info(sclp, sccb);
break;
case SCLP_CMDW_CONFIGURE_IOA:
sclp_configure_io_adapter(sclp, sccb, true);
break;
case SCLP_CMDW_DECONFIGURE_IOA:
sclp_configure_io_adapter(sclp, sccb, false);
break;
default:
s390x/event-facility: code restructure Code restructure in order to simplify class hierarchy - remove S390SCLPDevice abstract base class and move function pointers into new SCLPEventFacilityClass - implement SCLPEventFacility as SysBusDevice - use define constants for instance creation strings The following ascii-art shows the class structure wrt the SCLP EventFacility before (CURRENT) and after the restructure (NEW): ---- CURRENT: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacility | - to be replaced by new SCLPEventFacility, |-------------------------| which will be a SysBusDevice |SCLPEventsBus sbus | |DeviceState *qdev | |unsigned int receive_mask| +-------------------------+ +-------------------------+ | S390SCLPDeviceClass | - to be replaced by new SCLPEventFacilityClass |-------------------------| |DeviceClass qdev | |*(init)() | +-------------------------+ "s390-sclp-event-facility" | instance-of | V "s390-sclp-device" - this is an abstract class +-------------------------+ | S390SCLPDevice (A)| - to be replaced by new SCLPEventFacility |-------------------------| |SysBusDevice busdev | |SCLPEventFacility *ef | | | |*(sclp_command_handler)()| - these 2 go to new SCLPEventFacilityClass |*(event_pending)() | +-------------------------+ ---- NEW: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacilityClass | |-------------------------| |DeviceClass parent_class | | | |*(init)() | |*(command_handler)() | |*(event_pending)() | +-------------------------+ "s390-sclp-event-facility" +-------------------------+ | SCLPEventFacility | |-------------------------| |SysBusDevice parent_class| |SCLPEventsBus sbus | |unsigned int receive_mask| +-------------------------+ Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-12-18 10:10:49 +01:00
efc->command_handler(ef, sccb, code);
break;
}
}
/*
* We only need the address to have something valid for the
* service_interrupt call.
*/
#define SCLP_PV_DUMMY_ADDR 0x4000
int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb,
uint32_t code)
{
SCLPDevice *sclp = get_sclp_device();
SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
SCCBHeader header;
g_autofree SCCB *work_sccb = NULL;
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));
if (!sclp_command_code_valid(code)) {
work_sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
goto out_write;
}
sclp_c->execute(sclp, work_sccb, code);
out_write:
s390_cpu_pv_mem_write(env_archcpu(env), 0, work_sccb,
be16_to_cpu(work_sccb->h.length));
sclp_c->service_interrupt(sclp, SCLP_PV_DUMMY_ADDR);
return 0;
}
int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code)
{
SCLPDevice *sclp = get_sclp_device();
SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
SCCBHeader header;
g_autofree SCCB *work_sccb = NULL;
/* first some basic checks on program checks */
if (env->psw.mask & PSW_MASK_PSTATE) {
return -PGM_PRIVILEGED;
}
if (cpu_physical_memory_is_io(sccb)) {
return -PGM_ADDRESSING;
}
if ((sccb & ~0x1fffUL) == 0 || (sccb & ~0x1fffUL) == env->psa
|| (sccb & ~0x7ffffff8UL) != 0) {
return -PGM_SPECIFICATION;
}
/* 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;
}
/*
* 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
*/
work_sccb = g_malloc0(be16_to_cpu(header.length));
cpu_physical_memory_read(sccb, work_sccb, be16_to_cpu(header.length));
if (!sclp_command_code_valid(code)) {
work_sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
goto out_write;
}
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 21:44:14 +02:00
if (!sccb_verify_boundary(sccb, be16_to_cpu(work_sccb->h.length), code)) {
work_sccb->h.response_code = cpu_to_be16(SCLP_RC_SCCB_BOUNDARY_VIOLATION);
goto out_write;
}
sclp_c->execute(sclp, work_sccb, code);
out_write:
cpu_physical_memory_write(sccb, work_sccb,
be16_to_cpu(work_sccb->h.length));
sclp_c->service_interrupt(sclp, sccb);
return 0;
}
static void service_interrupt(SCLPDevice *sclp, uint32_t sccb)
{
SCLPEventFacility *ef = sclp->event_facility;
s390x/event-facility: code restructure Code restructure in order to simplify class hierarchy - remove S390SCLPDevice abstract base class and move function pointers into new SCLPEventFacilityClass - implement SCLPEventFacility as SysBusDevice - use define constants for instance creation strings The following ascii-art shows the class structure wrt the SCLP EventFacility before (CURRENT) and after the restructure (NEW): ---- CURRENT: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacility | - to be replaced by new SCLPEventFacility, |-------------------------| which will be a SysBusDevice |SCLPEventsBus sbus | |DeviceState *qdev | |unsigned int receive_mask| +-------------------------+ +-------------------------+ | S390SCLPDeviceClass | - to be replaced by new SCLPEventFacilityClass |-------------------------| |DeviceClass qdev | |*(init)() | +-------------------------+ "s390-sclp-event-facility" | instance-of | V "s390-sclp-device" - this is an abstract class +-------------------------+ | S390SCLPDevice (A)| - to be replaced by new SCLPEventFacility |-------------------------| |SysBusDevice busdev | |SCLPEventFacility *ef | | | |*(sclp_command_handler)()| - these 2 go to new SCLPEventFacilityClass |*(event_pending)() | +-------------------------+ ---- NEW: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacilityClass | |-------------------------| |DeviceClass parent_class | | | |*(init)() | |*(command_handler)() | |*(event_pending)() | +-------------------------+ "s390-sclp-event-facility" +-------------------------+ | SCLPEventFacility | |-------------------------| |SysBusDevice parent_class| |SCLPEventsBus sbus | |unsigned int receive_mask| +-------------------------+ Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-12-18 10:10:49 +01:00
SCLPEventFacilityClass *efc = EVENT_FACILITY_GET_CLASS(ef);
uint32_t param = sccb & ~3;
/* Indicate whether an event is still pending */
s390x/event-facility: code restructure Code restructure in order to simplify class hierarchy - remove S390SCLPDevice abstract base class and move function pointers into new SCLPEventFacilityClass - implement SCLPEventFacility as SysBusDevice - use define constants for instance creation strings The following ascii-art shows the class structure wrt the SCLP EventFacility before (CURRENT) and after the restructure (NEW): ---- CURRENT: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacility | - to be replaced by new SCLPEventFacility, |-------------------------| which will be a SysBusDevice |SCLPEventsBus sbus | |DeviceState *qdev | |unsigned int receive_mask| +-------------------------+ +-------------------------+ | S390SCLPDeviceClass | - to be replaced by new SCLPEventFacilityClass |-------------------------| |DeviceClass qdev | |*(init)() | +-------------------------+ "s390-sclp-event-facility" | instance-of | V "s390-sclp-device" - this is an abstract class +-------------------------+ | S390SCLPDevice (A)| - to be replaced by new SCLPEventFacility |-------------------------| |SysBusDevice busdev | |SCLPEventFacility *ef | | | |*(sclp_command_handler)()| - these 2 go to new SCLPEventFacilityClass |*(event_pending)() | +-------------------------+ ---- NEW: "s390-sclp-events-bus" +-------------------------+ | SCLPEventsBus | |-------------------------| |BusState qbus | +-------------------------+ +-------------------------+ | SCLPEventFacilityClass | |-------------------------| |DeviceClass parent_class | | | |*(init)() | |*(command_handler)() | |*(event_pending)() | +-------------------------+ "s390-sclp-event-facility" +-------------------------+ | SCLPEventFacility | |-------------------------| |SysBusDevice parent_class| |SCLPEventsBus sbus | |unsigned int receive_mask| +-------------------------+ Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-12-18 10:10:49 +01:00
param |= efc->event_pending(ef) ? 1 : 0;
if (!param) {
/* No need to send an interrupt, there's nothing to be notified about */
return;
}
s390_sclp_extint(param);
}
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);
}
/* qemu object creation and initialization functions */
void s390_sclp_init(void)
{
Object *new = object_new(TYPE_SCLP);
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 17:29:22 +02:00
object_property_add_child(qdev_get_machine(), TYPE_SCLP, new);
object_unref(new);
qdev_realize(DEVICE(new), NULL, &error_fatal);
}
static void sclp_realize(DeviceState *dev, Error **errp)
{
MachineState *machine = MACHINE(qdev_get_machine());
SCLPDevice *sclp = SCLP(dev);
uint64_t hw_limit;
int ret;
/*
* 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.
*/
if (!sysbus_realize(SYS_BUS_DEVICE(sclp->event_facility), errp)) {
return;
}
ret = s390_set_memory_limit(machine->maxram_size, &hw_limit);
if (ret == -E2BIG) {
error_setg(errp, "host supports a maximum of %" PRIu64 " GB",
hw_limit / GiB);
} else if (ret) {
error_setg(errp, "setting the guest size failed");
}
}
static void sclp_memory_init(SCLPDevice *sclp)
{
MachineState *machine = MACHINE(qdev_get_machine());
vl/s390x: fixup ram sizes for compat machines Older QEMU versions did fixup the ram size to match what can be reported via sclp. We need to mimic this behaviour for machine types 4.2 and older to not fail on inbound migration for memory sizes that do not fit. Old machines with proper aligned memory sizes are not affected. Alignment table: VM size (<=) | Alignment -------------------------- 1020M | 1M 2040M | 2M 4080M | 4M 8160M | 8M 16320M | 16M 32640M | 32M 65280M | 64M 130560M | 128M 261120M | 256M 522240M | 512M 1044480M | 1G 2088960M | 2G 4177920M | 4G 8355840M | 8G Suggested action is to replace unaligned -m value with a suitable aligned one or if a change to a newer machine type is possible, use a machine version >= 5.0. A future version might remove the compatibility handling. For machine types >= 5.0 we can simply use an increment size of 1M and use the full range of increment number which allows for all possible memory sizes. The old limitation of having a maximum of 1020 increments was added for standby memory, which we no longer support. With that we can now support even weird memory sizes like 10001234 MB. As we no longer fixup maxram_size as well, make other users use ram_size instead. Keep using maxram_size when setting the maximum ram size in KVM, as that will come in handy in the future when supporting memory hotplug (in contrast, storage keys and storage attributes for hotplugged memory will have to be migrated per RAM block in the future). Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200401123754.109602-1-borntraeger@de.ibm.com> [CH: fixed up message on memory size fixup] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-04-01 14:37:54 +02:00
MachineClass *machine_class = MACHINE_GET_CLASS(qdev_get_machine());
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.
vl/s390x: fixup ram sizes for compat machines Older QEMU versions did fixup the ram size to match what can be reported via sclp. We need to mimic this behaviour for machine types 4.2 and older to not fail on inbound migration for memory sizes that do not fit. Old machines with proper aligned memory sizes are not affected. Alignment table: VM size (<=) | Alignment -------------------------- 1020M | 1M 2040M | 2M 4080M | 4M 8160M | 8M 16320M | 16M 32640M | 32M 65280M | 64M 130560M | 128M 261120M | 256M 522240M | 512M 1044480M | 1G 2088960M | 2G 4177920M | 4G 8355840M | 8G Suggested action is to replace unaligned -m value with a suitable aligned one or if a change to a newer machine type is possible, use a machine version >= 5.0. A future version might remove the compatibility handling. For machine types >= 5.0 we can simply use an increment size of 1M and use the full range of increment number which allows for all possible memory sizes. The old limitation of having a maximum of 1020 increments was added for standby memory, which we no longer support. With that we can now support even weird memory sizes like 10001234 MB. As we no longer fixup maxram_size as well, make other users use ram_size instead. Keep using maxram_size when setting the maximum ram size in KVM, as that will come in handy in the future when supporting memory hotplug (in contrast, storage keys and storage attributes for hotplugged memory will have to be migrated per RAM block in the future). Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200401123754.109602-1-borntraeger@de.ibm.com> [CH: fixed up message on memory size fixup] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-04-01 14:37:54 +02:00
* For some machine types, the number of storage increments must be
* MAX_STORAGE_INCREMENTS or fewer.
* The variable 'increment_size' is an exponent of 2 that can be
* used to calculate the size (in bytes) of an increment. */
vl/s390x: fixup ram sizes for compat machines Older QEMU versions did fixup the ram size to match what can be reported via sclp. We need to mimic this behaviour for machine types 4.2 and older to not fail on inbound migration for memory sizes that do not fit. Old machines with proper aligned memory sizes are not affected. Alignment table: VM size (<=) | Alignment -------------------------- 1020M | 1M 2040M | 2M 4080M | 4M 8160M | 8M 16320M | 16M 32640M | 32M 65280M | 64M 130560M | 128M 261120M | 256M 522240M | 512M 1044480M | 1G 2088960M | 2G 4177920M | 4G 8355840M | 8G Suggested action is to replace unaligned -m value with a suitable aligned one or if a change to a newer machine type is possible, use a machine version >= 5.0. A future version might remove the compatibility handling. For machine types >= 5.0 we can simply use an increment size of 1M and use the full range of increment number which allows for all possible memory sizes. The old limitation of having a maximum of 1020 increments was added for standby memory, which we no longer support. With that we can now support even weird memory sizes like 10001234 MB. As we no longer fixup maxram_size as well, make other users use ram_size instead. Keep using maxram_size when setting the maximum ram size in KVM, as that will come in handy in the future when supporting memory hotplug (in contrast, storage keys and storage attributes for hotplugged memory will have to be migrated per RAM block in the future). Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200401123754.109602-1-borntraeger@de.ibm.com> [CH: fixed up message on memory size fixup] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-04-01 14:37:54 +02:00
while (machine_class->fixup_ram_size != NULL &&
(initial_mem >> increment_size) > MAX_STORAGE_INCREMENTS) {
increment_size++;
}
sclp->increment_size = increment_size;
}
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 17:29:22 +02:00
object_property_add_child(obj, TYPE_SCLP_EVENT_FACILITY, new);
object_unref(new);
sclp->event_facility = EVENT_FACILITY(new);
sclp_memory_init(sclp);
}
static void sclp_class_init(ObjectClass *oc, void *data)
{
SCLPDeviceClass *sc = SCLP_CLASS(oc);
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);
/*
* Reason: Creates TYPE_SCLP_EVENT_FACILITY in sclp_init
* which is a non-pluggable sysbus device
*/
dc->user_creatable = false;
sc->read_SCP_info = read_SCP_info;
sc->read_cpu_info = sclp_read_cpu_info;
sc->execute = sclp_execute;
sc->service_interrupt = service_interrupt;
}
static const TypeInfo sclp_info = {
.name = TYPE_SCLP,
.parent = TYPE_DEVICE,
.instance_init = sclp_init,
.instance_size = sizeof(SCLPDevice),
.class_init = sclp_class_init,
.class_size = sizeof(SCLPDeviceClass),
};
static void register_types(void)
{
type_register_static(&sclp_info);
}
type_init(register_types);