From nobody Sun Nov 9 19:12:54 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1551701282640648.7626195478136; Mon, 4 Mar 2019 04:08:02 -0800 (PST) Received: from localhost ([127.0.0.1]:52759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0mNz-0003zB-KK for importer@patchew.org; Mon, 04 Mar 2019 07:07:59 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0mIs-0008SG-Gh for qemu-devel@nongnu.org; Mon, 04 Mar 2019 07:02:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h0mIk-0008Qb-Eo for qemu-devel@nongnu.org; Mon, 04 Mar 2019 07:02:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35892) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h0mIi-0008F3-8z; Mon, 04 Mar 2019 07:02:34 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D6661FED4; Mon, 4 Mar 2019 12:02:28 +0000 (UTC) Received: from localhost (ovpn-116-85.ams2.redhat.com [10.36.116.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54E4460F8D; Mon, 4 Mar 2019 12:02:28 +0000 (UTC) From: Cornelia Huck To: Peter Maydell Date: Mon, 4 Mar 2019 13:01:47 +0100 Message-Id: <20190304120210.31500-5-cohuck@redhat.com> In-Reply-To: <20190304120210.31500-1-cohuck@redhat.com> References: <20190304120210.31500-1-cohuck@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 04 Mar 2019 12:02:28 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 04/27] s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tony Krowiak , qemu-s390x@nongnu.org, Cornelia Huck , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Tony Krowiak 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=3D$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=3Don) To hot unplug a vfio-ap device using the QEMU device_del command: (qemu) device_del vfio-ap,sysfsdev=3D$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=3Don) 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 gu= est. 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 vf= io-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 descri= ption 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 resour= ce de-configuration for the guest when the vfio-ap device is unplugged. When t= he vfio-ap device is unrealized, the mdev device file descriptor is closed whi= ch 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 t= o the guest. Signed-off-by: Tony Krowiak Reviewed-by: Pierre Morel Reviewed-by: David Hildenbrand Reviewed-by: Halil Pasic Tested-by: Pierre Morel 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 --- hw/s390x/ap-bridge.c | 12 +++++++++++- hw/vfio/ap.c | 2 +- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/hw/s390x/ap-bridge.c b/hw/s390x/ap-bridge.c index 3795d30dd7c9..75ad0a66b9e2 100644 --- a/hw/s390x/ap-bridge.c +++ b/hw/s390x/ap-bridge.c @@ -39,6 +39,7 @@ static const TypeInfo ap_bus_info =3D { void s390_init_ap(void) { DeviceState *dev; + BusState *bus; =20 /* If no AP instructions then no need for AP bridge */ if (!s390_has_feat(S390_FEAT_AP)) { @@ -52,13 +53,18 @@ void s390_init_ap(void) qdev_init_nofail(dev); =20 /* Create bus on bridge device */ - qbus_create(TYPE_AP_BUS, dev, TYPE_AP_BUS); + bus =3D qbus_create(TYPE_AP_BUS, dev, TYPE_AP_BUS); + + /* Enable hotplugging */ + qbus_set_hotplug_handler(bus, OBJECT(dev), &error_abort); } =20 static void ap_bridge_class_init(ObjectClass *oc, void *data) { DeviceClass *dc =3D DEVICE_CLASS(oc); + HotplugHandlerClass *hc =3D HOTPLUG_HANDLER_CLASS(oc); =20 + hc->unplug =3D qdev_simple_device_unplug_cb; set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories); } =20 @@ -67,6 +73,10 @@ static const TypeInfo ap_bridge_info =3D { .parent =3D TYPE_SYS_BUS_DEVICE, .instance_size =3D 0, .class_init =3D ap_bridge_class_init, + .interfaces =3D (InterfaceInfo[]) { + { TYPE_HOTPLUG_HANDLER }, + { } + } }; =20 static void ap_register(void) diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c index 6166ccd47a4a..d8b79ebe53ae 100644 --- a/hw/vfio/ap.c +++ b/hw/vfio/ap.c @@ -169,7 +169,7 @@ static void vfio_ap_class_init(ObjectClass *klass, void= *data) set_bit(DEVICE_CATEGORY_MISC, dc->categories); dc->realize =3D vfio_ap_realize; dc->unrealize =3D vfio_ap_unrealize; - dc->hotpluggable =3D false; + dc->hotpluggable =3D true; dc->reset =3D vfio_ap_reset; dc->bus_type =3D TYPE_AP_BUS; } --=20 2.17.2