[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/2] implement the failover feature for assi
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/2] implement the failover feature for assigned network devices |
Date: |
Mon, 08 Apr 2019 07:26:16 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Eduardo Habkost <address@hidden> 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 (address@hidden) 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?
[...]