Quoting Michal Privoznik (mprivozn@xxxxxxxxxx): > On 03.01.2014 05:38, Serge Hallyn wrote: > > Hi, > > > > one of our tests was complaining that after an attach-device > > followed by detach-device, the device was still in the vm's > > apparmor whitelist. It turns out the device actually also > > still in the device's xml. qemuDomainDetachVirtioDiskDevice() > > is calling > > > > if (!qemuDomainWaitForDeviceRemoval(vm)) > > qemuDomainRemoveDiskDevice(driver, vm, detach); > > ret = 0; > > > > Return values for qemuDomainWaitForDeviceRemoval are: > > > > * -1 on error > > * 0 when DEVICE_DELETED event is unsupported > > * 1 when device removal finished > > * 2 device removal did not finish in QEMU_REMOVAL_WAIT_TIME > > > > Those don't seem in line with how the return value is used. (According > > to gdb, it is returning 2 in my case.) I don't understand how the async > > device removal proceeds, but if qemuDomainWaitForDeviceRemoval() > > returned an error (-1 or 2) should qemuDomainDetachVirtioDiskDevice() at > > least return an error, assuming it's not safe to call > > qemuDomainRemoveDiskDevice()? > > > > As it is, I get > > > > # serge@t1:~/qa-regression-testing/scripts$ virsh detach-device qatest-i386 /tmp/tmpivE45x/device.xml > > # Device detached successfully > > > > but the device is actually still in qatest-i386's xml. Seems like the > > caller should be informed that the device is still attached. Assuming > > I'm not completely mis-reading the situation. > > > > No, you're on the right track. Although, historically the Detach* APIs > were 'issue the request to the hypervisor' rather than 'issue the > request and wait for device to detach' (limiting myself to QEMU here). > Users had to check the XML then whether/then the device was really > removed. But just recently (since 1.1.1) we've modified the behaviour a > bit. In one thread we're issuing the detach request and (possibly) > waiting for qemu to detach the device in 5 secs > (qemuDomainRemoveDeviceWaitTime). Then, the event loop listens for > events on the monitor and whenever the DETACH event comes, the internal > domain definition is adjusted. > > This approach, however, requires qemu to be able to send the DETACH > event. So whenever qemu doesn't support the event, we remove the device > from XML straight away. In all other cases, the device is removed upon > event delivery. Hence, the only return value we care about is 0 (meaning So even if the event is received while we're still waiting, it will have been received and handled by another thread so we don't have to? That explains handling 1 and 2 return value the same way then, thanks :) > qemu doesn't support the event). All other return values are irrelevant > to us in the current context. Thanks very much. I'll update the testcase then. > BTW: device removal may require guest kernel cooperation (e.g. when > detaching a PCI device) - hence it may take ages to complete. -serge -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list