On Fri, Oct 24, 2014 at 09:15:42AM -0600, Jim Fehlig wrote: > Eric Blake wrote: > > On 10/23/2014 03:21 PM, Jim Fehlig wrote: > > > >> This patch fixes a few issues noted while enabling the TCK PCI device > >> hotplug tests. > >> > >> First, the call to node device dettach function misses parameters, resulting > >> in the following failure > >> > >> Failed test 'detached device from host OS' > >> at /usr/share/libvirt-tck/tests/domain/250-pci-host-hotplug.t line 90. > >> died: Usage: Sys::Virt::NodeDevice::dettach(dev, driversv, flags=0) > >> at /usr/share/libvirt-tck/tests/domain/250-pci-host-hotplug.t line 90. > >> > >> Trivally fixed by adding the missing parameters when calling node device > >> dettach function. > >> > > > > That part is fine to fix (note that 'dettach' is a typo but part of the > > API, so we are stuck with it; it's nice to use 'detach' where possible). > > > > > >> Second, it appears qemu needs to reach some state of initialization before > >> host device attach/detach works properly. Currently, the test fails when > >> detaching the device from the guest, resetting it, and reattaching it to > >> the host > >> > >> Failed test 'reset the host PCI device' > >> at /usr/share/libvirt-tck/tests/domain/250-pci-host-hotplug.t line 110. > >> died: Sys::Virt::Error (libvirt error code: 1, message: internal error: > >> Not resetting active device 0000:03:00.1) > >> > >> Failed test 'reattached device to host OS' > >> at /usr/share/libvirt-tck/tests/domain/250-pci-host-hotplug.t line 111. > >> died: Sys::Virt::Error (libvirt error code: 55, message: Requested operation > >> is not valid: PCI device 0000:03:00.1 is still in use by driver QEMU, domain > >> tck) > >> > >> I've found that sleeping for a bit after creating the guest allows the > >> tests to pass. > >> > > > > But that papers over the bug. Ideally, the libvirt API should be > > waiting longer for the guest to relinquish control of the device before > > returning success on the first call, so that the second call cannot hit > > a collision. > > Even with this delay, the guest has not completely booted when the test > successfully completes. So it is not clear to me how much guest > cooperation is needed. > > > I'm not so sure that this is the right patch to make to > > TCK, and wonder if we should instead be patching libvirt proper. Or is > > it a case that because detach requires guest cooperation, we need to > > wait long enough for the guest to boot to the point that it can > > cooperate? > > Perhaps. Maybe acpiphp needs to be loaded in the guest kernel before > this will work. Yeah, I'm a little fuzzy on just how functiuonal the guest OS has to be. I suspect the kernel mod is sufficient, so whether it finishes booting is probably not important as long as the mod is loaded. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list