From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwUTF-0006cU-KT for qemu-devel@nongnu.org; Mon, 25 Sep 2017 10:34:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwUTC-0008NY-GK for qemu-devel@nongnu.org; Mon, 25 Sep 2017 10:34:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40946) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dwUTC-0008Mo-6K for qemu-devel@nongnu.org; Mon, 25 Sep 2017 10:34:50 -0400 Date: Mon, 25 Sep 2017 11:34:39 -0300 From: Eduardo Habkost Message-ID: <20170925143439.GA3030@localhost.localdomain> References: <1506071794-4373-1-git-send-email-thuth@redhat.com> <20170925135316.74fed6da.cohuck@redhat.com> <20170925133153.GZ3030@localhost.localdomain> <20170925154647.357047b9@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170925154647.357047b9@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [PATCH v2] qdev: Mark devices as non-hotpluggable by default List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Cornelia Huck , Thomas Huth , qemu-devel@nongnu.org, Peter Maydell , Paolo Bonzini , Xiao Guangrong , "Michael S. Tsirkin" , Marcel Apfelbaum , Christian Borntraeger , Gerd Hoffmann , Stefano Stabellini , Anthony Perard , David Hildenbrand , David Gibson , Bharata B Rao , Amit Shah On Mon, Sep 25, 2017 at 03:46:47PM +0200, Igor Mammedov wrote: > On Mon, 25 Sep 2017 10:31:53 -0300 > Eduardo Habkost wrote: > > > On Mon, Sep 25, 2017 at 01:53:16PM +0200, Cornelia Huck wrote: > > > On Fri, 22 Sep 2017 11:16:34 +0200 > > > Thomas Huth wrote: > > > > > > > Historically we've marked all devices as hotpluggable by default. However, > > > > most devices are not hotpluggable, and you also need a HotplugHandler to > > > > support these devices. So if the user tries to "device_add" or "device_del" > > > > such a non-hotpluggable device during runtime, either nothing really usable > > > > happens, or QEMU even crashes/aborts unexpectedly (see for example commit > > > > 84ebd3e8c7d4fe955b - "Mark diag288 watchdog as non-hotpluggable"). > > > > So let's change this dangerous default behaviour and mark the devices as > > > > non-hotpluggable by default. Certain parent devices classes which are known > > > > as hotpluggable (e.g. PCI, USB, etc.) are marked with "hotpluggable = true", > > > > so that devices that are derived from these classes continue to work as > > > > expected. > > > > > > > > Signed-off-by: Thomas Huth > > > > --- > > > > v2: Add missing devices and dropped "RFC" status. See Eduardo's reply on > > > > the previous version of this patch for the rationale which devices need > > > > to be hotpluggable: > > > > https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg06128.html > > > > > > > > hw/char/virtio-serial-bus.c | 1 + > > > > hw/core/qdev.c | 10 ++++------ > > > > hw/mem/nvdimm.c | 3 +++ > > > > hw/mem/pc-dimm.c | 1 + > > > > hw/pci/pci.c | 1 + > > > > hw/ppc/spapr_cpu_core.c | 1 + > > > > hw/s390x/ccw-device.c | 1 + > > > > hw/scsi/scsi-bus.c | 1 + > > > > hw/usb/bus.c | 1 + > > > > hw/usb/dev-smartcard-reader.c | 1 + > > > > hw/xen/xen_backend.c | 1 + > > > > target/i386/cpu.c | 4 ++-- > > > > target/s390x/cpu.c | 1 + > > > > 13 files changed, 19 insertions(+), 8 deletions(-) > > > > > > Hm, this seems to break hotplug of virtio devices: > > > > > > (qemu) device_add virtio-net-pci,id=xxx > > > Device 'virtio-net-device' does not support hotplugging > > > > > > (qemu) device_add virtio-net-ccw,id=yyy > > > Device 'virtio-net-device' does not support hotplugging > > > > > > We probably need to enable hotplug for virtio devices as well? > > > > I've seen a similar case broken by "[PATCH] hw/core/qdev: Do not > > allow hot-plugging without hotplug controller", because we're > > blocking creation of devices created internally by other devices, > > not just the ones created by device_add. I need to find the > > exact reproducer again. > > > > It would probably simplify things if we move the check for > > DeviceClass::hotpluggable to qmp_device_add(), instead of > > device_set_realized(). > if we would have to do that, than we are probably doing > something wrong and not using property right. Perhaps we > should fix property instead of trying find a place to check > it where it would hurt less. I disagree. It depends on the purpose and semantics we define for DeviceClass::hotpluggable. My goal is to have a reliable way to tell the user if a device really supports device_add, and I think it wouldn't make sense to report hotpluggable=true on a device that is never instantiated directly by the user and only used internally. -- Eduardo