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. Does device_add allocate the host side PCI device? If yes, should it? [...]
