On Mon, Apr 08, 2019 at 07:26:16AM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabk...@redhat.com> writes: > > > On Fri, Apr 05, 2019 at 07:22:35PM -0400, Michael S. Tsirkin wrote: > >> On Fri, Apr 05, 2019 at 09:56:29AM +0100, Dr. David Alan Gilbert wrote: > >> > * Jens Freimann (jfreim...@redhat.com) wrote: > >> > > On Fri, Mar 22, 2019 at 02:44:45PM +0100, Jens Freimann wrote: > > [...] > >> > > > 3. Management layer software should handle this. Open Stack already > >> > > > has > >> > > > components/code to handle unplug/replug VFIO devices and metadata to > >> > > > provide to the guest for detecting which devices should be paired. > >> > > > -> An approach that includes all software from firmware to > >> > > > higher-level management software wasn't tried in the last years. > >> > > > This is > >> > > > an attempt to keep it simple and contained in QEMU as much as > >> > > > possible. > >> > > > 4. Hotplugging a device and then making it part of a failover setup > >> > > > is > >> > > > not possible > >> > > > -> addressed by extending qdev hotplug functions to check for hidden > >> > > > attribute, so e.g. device_add can be used to plug a device. > >> > > > > >> > > > There are still some open issues: > >> > > > > >> > > > Migration: I'm looking for something like a pre-migration hook that I > >> > > > could use to unplug the vfio-pci device. I tried with a migration > >> > > > notifier but it is called to late, i.e. after migration is aborted > >> > > > due > >> > > > to vfio-pci marked unmigrateable. I worked around this by setting it > >> > > > to migrateable and used a migration notifier on the virtio-net > >> > > > device. > >> > > >> > Why not just let this happen at the libvirt level; then you do the > >> > hotunplug etc before you actually tell qemu anything about starting a > >> > migration? > >> > >> If qemu frees up resources (as it does on unplug) then libvirt > >> is not guaranteed it can roll the change back on e.g. > >> migration failure. > > > > Why should we always free up resources on unplug? > > > > Unplug of a disk device doesn't close the corresponding -blockdev. > > It does for block backends created with -drive, and that was a mistake > we corrected with -blockdev. > > > Unplug of a serial device doesn't close the corresponding -chardev. > > Unplug of a memory device doesn't close the corresponding memory backend. > > Unplug of a crypto device doesn't close the corresponding crypto backend. > > > > Why do we expect device_del of a passthrough PCI device to always > > release the host side PCI device? We can provide a better API > > than that. > > device_del should free what device_add allocates.
Absolutely. Making unplug of the guest device not close the host device implies in having the host device not being opened by device_add (it would be opened by -object/object_add, I assume). > > Does device_add allocate the host side PCI device? If yes, should it? I don't see any reason it should. -- Eduardo
