mirror_qemu/hw/s390x/ap-bridge.c

91 lines
2.1 KiB
C
Raw Normal View History

/*
* ap bridge
*
* Copyright 2018 IBM Corp.
*
* 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 "qapi/error.h"
#include "hw/sysbus.h"
#include "qemu/bitops.h"
#include "qemu/module.h"
#include "hw/s390x/ap-bridge.h"
#include "cpu.h"
static char *ap_bus_get_dev_path(DeviceState *dev)
{
/* at most one */
return g_strdup_printf("/1");
}
static void ap_bus_class_init(ObjectClass *oc, void *data)
{
BusClass *k = BUS_CLASS(oc);
k->get_dev_path = ap_bus_get_dev_path;
/* More than one ap device does not make sense */
k->max_dev = 1;
}
static const TypeInfo ap_bus_info = {
.name = TYPE_AP_BUS,
.parent = TYPE_BUS,
.instance_size = 0,
.class_init = ap_bus_class_init,
};
void s390_init_ap(void)
{
DeviceState *dev;
s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device Introduces hot plug/unplug support for the vfio-ap device. To hot plug a vfio-ap device using the QEMU device_add command: (qemu) device_add vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device to which AP resources to be used by the guest have been assigned. A vfio-ap device can be hot plugged only if: 1. A vfio-ap device has not been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) To hot unplug a vfio-ap device using the QEMU device_del command: (qemu) device_del vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device specified when the vfio-ap device was attached to the virtual machine's ap-bus. A vfio-ap device can be hot unplugged only if: 1. A vfio-ap device has been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) Please note that a hot plug handler is not necessary for the vfio-ap device because the AP matrix configuration for the guest is performed by the kernel device driver when the vfio-ap device is realized. The vfio-ap device represents a VFIO mediated device created in the host sysfs for use by a guest. The mdev device is configured with an AP matrix (i.e., adapters and domains) via its sysfs attribute interfaces prior to starting the guest or plugging a vfio-ap device in. When the device is realized, a file descriptor is opened on the mdev device which results in a callback to the vfio_ap kernel device driver. The device driver then configures the AP matrix in the guest's SIE state description from the AP matrix assigned via the mdev device's sysfs interfaces. The AP devices will be created for the guest when the AP bus running on the guest subsequently performs its periodic scan for AP devices. The qdev_simple_device_unplug_cb() callback function is used for the same reaons; namely, the vfio_ap kernel device driver will perform the AP resource de-configuration for the guest when the vfio-ap device is unplugged. When the vfio-ap device is unrealized, the mdev device file descriptor is closed which results in a callback to the vfio_ap kernel device driver. The device driver then clears the AP matrix configuration in the guest's SIE state description and resets all of the affected queues. The AP devices created for the guest will be removed when the AP bus running on the guest subsequently performs its periodic scan and finds there are no longer any AP resources assigned to the guest. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <1550519397-25359-2-git-send-email-akrowiak@linux.ibm.com> [CH: adapt to changed qbus_set_hotplug_handler() signature] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18 22:49:56 +03:00
BusState *bus;
/* If no AP instructions then no need for AP bridge */
if (!s390_has_feat(S390_FEAT_AP)) {
return;
}
/* Create bridge device */
qdev: Convert uses of qdev_create() with Coccinelle This is the transformation explained in the commit before previous. Takes care of just one pattern that needs conversion. More to come in this series. Coccinelle script: @ depends on !(file in "hw/arm/highbank.c")@ expression bus, type_name, dev, expr; @@ - dev = qdev_create(bus, type_name); + dev = qdev_new(type_name); ... when != dev = expr - qdev_init_nofail(dev); + qdev_realize_and_unref(dev, bus, &error_fatal); @@ expression bus, type_name, dev, expr; identifier DOWN; @@ - dev = DOWN(qdev_create(bus, type_name)); + dev = DOWN(qdev_new(type_name)); ... when != dev = expr - qdev_init_nofail(DEVICE(dev)); + qdev_realize_and_unref(DEVICE(dev), bus, &error_fatal); @@ expression bus, type_name, expr; identifier dev; @@ - DeviceState *dev = qdev_create(bus, type_name); + DeviceState *dev = qdev_new(type_name); ... when != dev = expr - qdev_init_nofail(dev); + qdev_realize_and_unref(dev, bus, &error_fatal); @@ expression bus, type_name, dev, expr, errp; symbol true; @@ - dev = qdev_create(bus, type_name); + dev = qdev_new(type_name); ... when != dev = expr - object_property_set_bool(OBJECT(dev), true, "realized", errp); + qdev_realize_and_unref(dev, bus, errp); @@ expression bus, type_name, expr, errp; identifier dev; symbol true; @@ - DeviceState *dev = qdev_create(bus, type_name); + DeviceState *dev = qdev_new(type_name); ... when != dev = expr - object_property_set_bool(OBJECT(dev), true, "realized", errp); + qdev_realize_and_unref(dev, bus, errp); The first rule exempts hw/arm/highbank.c, because it matches along two control flow paths there, with different @type_name. Covered by the next commit's manual conversions. Missing #include "qapi/error.h" added manually. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-10-armbru@redhat.com> [Conflicts in hw/misc/empty_slot.c and hw/sparc/leon3.c resolved]
2020-06-10 08:31:58 +03:00
dev = qdev_new(TYPE_AP_BRIDGE);
object_property_add_child(qdev_get_machine(), TYPE_AP_BRIDGE,
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(dev));
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
/* Create bus on bridge device */
s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device Introduces hot plug/unplug support for the vfio-ap device. To hot plug a vfio-ap device using the QEMU device_add command: (qemu) device_add vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device to which AP resources to be used by the guest have been assigned. A vfio-ap device can be hot plugged only if: 1. A vfio-ap device has not been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) To hot unplug a vfio-ap device using the QEMU device_del command: (qemu) device_del vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device specified when the vfio-ap device was attached to the virtual machine's ap-bus. A vfio-ap device can be hot unplugged only if: 1. A vfio-ap device has been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) Please note that a hot plug handler is not necessary for the vfio-ap device because the AP matrix configuration for the guest is performed by the kernel device driver when the vfio-ap device is realized. The vfio-ap device represents a VFIO mediated device created in the host sysfs for use by a guest. The mdev device is configured with an AP matrix (i.e., adapters and domains) via its sysfs attribute interfaces prior to starting the guest or plugging a vfio-ap device in. When the device is realized, a file descriptor is opened on the mdev device which results in a callback to the vfio_ap kernel device driver. The device driver then configures the AP matrix in the guest's SIE state description from the AP matrix assigned via the mdev device's sysfs interfaces. The AP devices will be created for the guest when the AP bus running on the guest subsequently performs its periodic scan for AP devices. The qdev_simple_device_unplug_cb() callback function is used for the same reaons; namely, the vfio_ap kernel device driver will perform the AP resource de-configuration for the guest when the vfio-ap device is unplugged. When the vfio-ap device is unrealized, the mdev device file descriptor is closed which results in a callback to the vfio_ap kernel device driver. The device driver then clears the AP matrix configuration in the guest's SIE state description and resets all of the affected queues. The AP devices created for the guest will be removed when the AP bus running on the guest subsequently performs its periodic scan and finds there are no longer any AP resources assigned to the guest. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <1550519397-25359-2-git-send-email-akrowiak@linux.ibm.com> [CH: adapt to changed qbus_set_hotplug_handler() signature] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18 22:49:56 +03:00
bus = qbus_create(TYPE_AP_BUS, dev, TYPE_AP_BUS);
/* Enable hotplugging */
qbus_set_hotplug_handler(bus, OBJECT(dev));
}
static void ap_bridge_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device Introduces hot plug/unplug support for the vfio-ap device. To hot plug a vfio-ap device using the QEMU device_add command: (qemu) device_add vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device to which AP resources to be used by the guest have been assigned. A vfio-ap device can be hot plugged only if: 1. A vfio-ap device has not been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) To hot unplug a vfio-ap device using the QEMU device_del command: (qemu) device_del vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device specified when the vfio-ap device was attached to the virtual machine's ap-bus. A vfio-ap device can be hot unplugged only if: 1. A vfio-ap device has been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) Please note that a hot plug handler is not necessary for the vfio-ap device because the AP matrix configuration for the guest is performed by the kernel device driver when the vfio-ap device is realized. The vfio-ap device represents a VFIO mediated device created in the host sysfs for use by a guest. The mdev device is configured with an AP matrix (i.e., adapters and domains) via its sysfs attribute interfaces prior to starting the guest or plugging a vfio-ap device in. When the device is realized, a file descriptor is opened on the mdev device which results in a callback to the vfio_ap kernel device driver. The device driver then configures the AP matrix in the guest's SIE state description from the AP matrix assigned via the mdev device's sysfs interfaces. The AP devices will be created for the guest when the AP bus running on the guest subsequently performs its periodic scan for AP devices. The qdev_simple_device_unplug_cb() callback function is used for the same reaons; namely, the vfio_ap kernel device driver will perform the AP resource de-configuration for the guest when the vfio-ap device is unplugged. When the vfio-ap device is unrealized, the mdev device file descriptor is closed which results in a callback to the vfio_ap kernel device driver. The device driver then clears the AP matrix configuration in the guest's SIE state description and resets all of the affected queues. The AP devices created for the guest will be removed when the AP bus running on the guest subsequently performs its periodic scan and finds there are no longer any AP resources assigned to the guest. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <1550519397-25359-2-git-send-email-akrowiak@linux.ibm.com> [CH: adapt to changed qbus_set_hotplug_handler() signature] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18 22:49:56 +03:00
HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device Introduces hot plug/unplug support for the vfio-ap device. To hot plug a vfio-ap device using the QEMU device_add command: (qemu) device_add vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device to which AP resources to be used by the guest have been assigned. A vfio-ap device can be hot plugged only if: 1. A vfio-ap device has not been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) To hot unplug a vfio-ap device using the QEMU device_del command: (qemu) device_del vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device specified when the vfio-ap device was attached to the virtual machine's ap-bus. A vfio-ap device can be hot unplugged only if: 1. A vfio-ap device has been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) Please note that a hot plug handler is not necessary for the vfio-ap device because the AP matrix configuration for the guest is performed by the kernel device driver when the vfio-ap device is realized. The vfio-ap device represents a VFIO mediated device created in the host sysfs for use by a guest. The mdev device is configured with an AP matrix (i.e., adapters and domains) via its sysfs attribute interfaces prior to starting the guest or plugging a vfio-ap device in. When the device is realized, a file descriptor is opened on the mdev device which results in a callback to the vfio_ap kernel device driver. The device driver then configures the AP matrix in the guest's SIE state description from the AP matrix assigned via the mdev device's sysfs interfaces. The AP devices will be created for the guest when the AP bus running on the guest subsequently performs its periodic scan for AP devices. The qdev_simple_device_unplug_cb() callback function is used for the same reaons; namely, the vfio_ap kernel device driver will perform the AP resource de-configuration for the guest when the vfio-ap device is unplugged. When the vfio-ap device is unrealized, the mdev device file descriptor is closed which results in a callback to the vfio_ap kernel device driver. The device driver then clears the AP matrix configuration in the guest's SIE state description and resets all of the affected queues. The AP devices created for the guest will be removed when the AP bus running on the guest subsequently performs its periodic scan and finds there are no longer any AP resources assigned to the guest. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <1550519397-25359-2-git-send-email-akrowiak@linux.ibm.com> [CH: adapt to changed qbus_set_hotplug_handler() signature] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18 22:49:56 +03:00
hc->unplug = qdev_simple_device_unplug_cb;
set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
}
static const TypeInfo ap_bridge_info = {
.name = TYPE_AP_BRIDGE,
.parent = TYPE_SYS_BUS_DEVICE,
.instance_size = 0,
.class_init = ap_bridge_class_init,
s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device Introduces hot plug/unplug support for the vfio-ap device. To hot plug a vfio-ap device using the QEMU device_add command: (qemu) device_add vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device to which AP resources to be used by the guest have been assigned. A vfio-ap device can be hot plugged only if: 1. A vfio-ap device has not been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) To hot unplug a vfio-ap device using the QEMU device_del command: (qemu) device_del vfio-ap,sysfsdev=$path-to-mdev Where $path-to-mdev is the absolute path to the mediated matrix device specified when the vfio-ap device was attached to the virtual machine's ap-bus. A vfio-ap device can be hot unplugged only if: 1. A vfio-ap device has been attached to the virtual machine's ap-bus via the QEMU command line or a prior hot plug action. 2. The guest was started with the CPU model feature for AP enabled (e.g., -cpu host,ap=on) Please note that a hot plug handler is not necessary for the vfio-ap device because the AP matrix configuration for the guest is performed by the kernel device driver when the vfio-ap device is realized. The vfio-ap device represents a VFIO mediated device created in the host sysfs for use by a guest. The mdev device is configured with an AP matrix (i.e., adapters and domains) via its sysfs attribute interfaces prior to starting the guest or plugging a vfio-ap device in. When the device is realized, a file descriptor is opened on the mdev device which results in a callback to the vfio_ap kernel device driver. The device driver then configures the AP matrix in the guest's SIE state description from the AP matrix assigned via the mdev device's sysfs interfaces. The AP devices will be created for the guest when the AP bus running on the guest subsequently performs its periodic scan for AP devices. The qdev_simple_device_unplug_cb() callback function is used for the same reaons; namely, the vfio_ap kernel device driver will perform the AP resource de-configuration for the guest when the vfio-ap device is unplugged. When the vfio-ap device is unrealized, the mdev device file descriptor is closed which results in a callback to the vfio_ap kernel device driver. The device driver then clears the AP matrix configuration in the guest's SIE state description and resets all of the affected queues. The AP devices created for the guest will be removed when the AP bus running on the guest subsequently performs its periodic scan and finds there are no longer any AP resources assigned to the guest. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <1550519397-25359-2-git-send-email-akrowiak@linux.ibm.com> [CH: adapt to changed qbus_set_hotplug_handler() signature] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18 22:49:56 +03:00
.interfaces = (InterfaceInfo[]) {
{ TYPE_HOTPLUG_HANDLER },
{ }
}
};
static void ap_register(void)
{
type_register_static(&ap_bridge_info);
type_register_static(&ap_bus_info);
}
type_init(ap_register)