From: Tony Krowiak <akrowiak@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-s390x@nongnu.org, borntraeger@de.ibm.com, cohuck@redhat.com,
pmorel@linux.ibm.com, alifm@linux.ibm.com,
mjrosato@linux.ibm.com, jjherne@linux.ibm.com,
pasic@linux.vnet.ibm.com, alex.williamson@redhat.com,
peter.maydell@linaro.org, rth@twiddle.net, fiuczy@linux.ibm.com
Subject: Re: [Qemu-devel] [PATCH] s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device
Date: Tue, 8 Jan 2019 14:52:32 -0500 [thread overview]
Message-ID: <54bc1f9c-e997-cb1b-77cb-0dce478fafdc@linux.ibm.com> (raw)
In-Reply-To: <5a7e9130-30d1-84ad-0737-5023b718b99c@redhat.com>
On 1/8/19 11:09 AM, David Hildenbrand wrote:
> On 08.01.19 17:01, Tony Krowiak wrote:
>> Introduces hot plug/unplug support for the vfio-ap device. Note that only one
>> vfio-ap device can be attached to the ap-bus, so a vfio-ap device can only be
>> hot plugged if the '-device vfio-ap,sysfsdev=$path_to_mdev' option is not
>> specified on the QEMU command line.
>>
>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> Reviewed-by: Pierre Morel<pmorel@linux.ibm.com>
>> Tested-by: Pierre Morel<pmorel@linux.ibm.com>
>> ---
>> 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..25a03412fcb9 100644
>> --- a/hw/s390x/ap-bridge.c
>> +++ b/hw/s390x/ap-bridge.c
>> @@ -39,6 +39,7 @@ static const TypeInfo ap_bus_info = {
>> void s390_init_ap(void)
>> {
>> DeviceState *dev;
>> + BusState *bus;
>>
>> /* 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);
>>
>> /* Create bus on bridge device */
>> - qbus_create(TYPE_AP_BUS, dev, TYPE_AP_BUS);
>> + bus = qbus_create(TYPE_AP_BUS, dev, TYPE_AP_BUS);
>> +
>> + /* Enable hotplugging */
>> + qbus_set_hotplug_handler(bus, dev, &error_abort);
>> }
>>
>> static void ap_bridge_class_init(ObjectClass *oc, void *data)
>> {
>> DeviceClass *dc = DEVICE_CLASS(oc);
>> + HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
>>
>> + hc->unplug = qdev_simple_device_unplug_cb;
>
> confused, why is there no plug action?
You will find this is the case for several devices that are hot
pluggable. The plug callback is invoked after the device is
attached to the bus and after the device is realized. Not having
a hot plug callback does not preclude hot plugging of a device.
I presume the purpose of the callback is to provide an opportunity
to do perform any additional processing that may be required to prepare
the device for use. In the case of the vfio-ap device, there is nothing
to do once the device is plugged.
>
>> set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
>> }
>>
>> @@ -67,6 +73,10 @@ static const TypeInfo ap_bridge_info = {
>> .parent = TYPE_SYS_BUS_DEVICE,
>> .instance_size = 0,
>> .class_init = ap_bridge_class_init,
>> + .interfaces = (InterfaceInfo[]) {
>> + { TYPE_HOTPLUG_HANDLER },
>> + { }
>> + }
>> };
>>
>> 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 = vfio_ap_realize;
>> dc->unrealize = vfio_ap_unrealize;
>> - dc->hotpluggable = false;
>> + dc->hotpluggable = true;
>> dc->reset = vfio_ap_reset;
>> dc->bus_type = TYPE_AP_BUS;
>> }
>>
>
>
next prev parent reply other threads:[~2019-01-08 19:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-08 16:01 [Qemu-devel] [PATCH] s390x/vfio-ap: Implement hot plug/unplug of vfio-ap device Tony Krowiak
2019-01-08 16:09 ` David Hildenbrand
2019-01-08 19:52 ` Tony Krowiak [this message]
2019-01-08 22:13 ` David Hildenbrand
2019-01-09 11:30 ` Cornelia Huck
2019-01-09 16:27 ` Tony Krowiak
2019-01-09 16:37 ` David Hildenbrand
2019-01-09 17:13 ` Halil Pasic
2019-01-09 17:28 ` David Hildenbrand
2019-01-10 16:22 ` Tony Krowiak
2019-01-14 14:16 ` Cornelia Huck
2019-01-28 19:27 ` Tony Krowiak
2019-01-08 16:14 ` Tony Krowiak
2019-01-09 17:05 ` [Qemu-devel] [qemu-s390x] " Halil Pasic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54bc1f9c-e997-cb1b-77cb-0dce478fafdc@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=fiuczy@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.vnet.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).