qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v4 4/7] qdev: add hotpluggable to DeviceState
Date: Mon, 26 Feb 2018 09:23:48 +0100
User-agent: NeoMutt/20180223

  Hi,

> > The connection between QemuConsole and User Interface (i.e. gtk, spice,
> > ...) is a bit more flexible.  But also not really designed for hotplug
> > as QemuConsole is not hotpluggable in the first place ...
> > 
> > We could drop the display property and use two devices instead.
> > 
> >   new vfio-pci would behave like display=off with this series.
> >   added vfio-pci-display has display=on behavior.
> >   display=auto is not possible.
> 
> I expect libvirt and above would balk at creating a separate QEMU
> device for this purpose, easy for QEMU, hard for anything that manages
> QEMU.

Now as you've mentioned libvirt I remember we had the same discussion
before, with usb host adapters.  The uhci and ehci controllers have a
simliar issue:  If they are configured as companion setup (ehci for usb2
and uhci for usb1) they can't be hotplugged, as standalone controller
hotplugging works fine.

We ended up with splitting the controllers into two groups:  The ones
which can be used in a companion setup (basically all ich9-* devices)
which are not hotpluggable.   And the other ones which don't support
companion setups but can be hotplugged.  Commits:

   ec56214f6f usb: tag standalone ehci as hotpluggable
   638ca939d8 usb: tag standalone uhci as hotpluggable

The argument from the libvirt side was that it is actually easier for
them to handle if hotplugging is a fixed property of a device and
doesn't change magically depending on device configuration.  First
because they can query qemu then whenever a given device can be
hotplugged or not, and second because it'll work for both plug-in and
plug-out.

So this patch isn't going to fly, and unless someone can come up with a
better idea I'll go use the two-devices approach.

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]