On 03.09.2019 22:40, Daniel Henrique Barboza wrote: > Hi Nikolay, > > I was going to review these patches but first I followed up in the > discussions at [1]. Daniel made a few points there: > > --- > The problems around host USB device passthrough are conceptually similar > to the problems of hots PCI device passthrough. > > In both cases we cannot assume the device present on the source device > exists on the target device in the same way. > (...) > For PCI devices we simply refuse to initiate the migration if any host > PCI devices are attached. The mgmt app has to hot-unplug all devices > before migration, and hot-plug new devices after migration if desired. > > I'm inclined to suggest that same approach of hotunplug + hotplug either > side of migration is the only viable option for host USB devices too. > (...) > --- > > My question: is this patch series still alive? Seems to me that you made > these changes based at least partially with migration in mind, and > the migration solution Libvirt adopted is to rely on upper management > to detach/reattach hostdev devices prior/before migration. Hi, Daniel. I'm going to send 2nd version of the patchset without using dummy device as suggested by Dan. Nikolay > > > Thanks, > > > DHB > > > On 8/30/19 9:08 AM, Nikolay Shirokovskiy wrote: >> Hi, all. >> >> This patch series aims to handle case when hostdev usb is detached and then >> attached back on node. Currently libvirtd does not track these events so that in >> the result hostdev usb is not usable. >> >> On the first glace it make sense to delete device from qemu when hostdev is >> detached on node and then add device back when hostdev is attached back. But >> these series adds a different behaviour. On detaching device is deleted from >> qemu and dummy (missing hostaddr and hostbus values) hostdev is inserted, then >> on attaching device on node dummy device is deleted and proper one is inserted. >> This way we have the same semantics of 'missing' flag for hostdev as in case of >> hostdev missing on startup/migration to different host. Also with such >> approach we additionally handle cases when hostdev is missing on startup but >> later is attached to node. >> >> Known issues: >> >> The last patch tries to handle case when hostdev attached/detached when >> libvirtd is down but if fails in one scenario. If hostdev is detached and thus >> dummy device in inserted in qemu then if libvirtd is down and hostdev is >> attached to node then qemu tries to bind appeared hostdev to the dummy device >> but fails as device is missing in qemu's mount namespace. Later when libvirtd >> is up and tries to replace dummy device with actual one the device_add fails >> because libusb the qemu uses tracks that deviced was missed ealier. For this >> reason I proposed to get rid of dummy device in RFC [1]. Alternatively libusb >> can be fixed. >> >> [1] https://www.redhat.com/archives/libvir-list/2019-August/msg01396.html >> >> Nikolay Shirokovskiy (6): >> qemu: track hostdev delete cause >> qemu: handle usb hostdev add/del udev events >> qemu: handle usb hostdev add/del on device DELETED_EVENT >> conf: parse hostdev missing flag >> qemu: handle libvirtd restarts during hostdev reattaching >> qemu: handle hostdev add/del when libvirtd is down >> >> src/conf/domain_conf.c | 32 ++++ >> src/conf/domain_conf.h | 10 ++ >> src/qemu/Makefile.inc.am | 2 + >> src/qemu/qemu_conf.h | 3 + >> src/qemu/qemu_domain.c | 2 + >> src/qemu/qemu_domain.h | 2 + >> src/qemu/qemu_driver.c | 376 +++++++++++++++++++++++++++++++++++++-- >> src/qemu/qemu_hotplug.c | 94 ++++++++-- >> src/qemu/qemu_hotplug.h | 7 +- >> src/qemu/qemu_process.c | 55 +++++- >> src/util/virhostdev.c | 6 +- >> tests/qemuhotplugtest.c | 2 +- >> 12 files changed, 558 insertions(+), 33 deletions(-) >> > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
