On Tue, 2016-03-15 at 14:38 -0400, John Ferlan wrote: > > As for your question, a device might end up in the inactive > > list because of: > > > > * PreparePCIDevices(), step 2, if managed. Just temporarily, > > it's moved to the active list in step 5 > > > > * ReattachPCIDevices(), step 4, whether managed or > > unmanaged. If it's managed is also removed from the > > inactive list in the same step, if it's unmanaged it > > will remain in the inactive list > > > > * PCINodeDeviceDetach() > > > > This is not including rollback paths. So it ends up in the > > inactive list when it's either *not yet* active, or *no > > longer* active. > > > > > I don't disagree this is an important step, but it's the "how" we > > > determine this that I'm questioning. > > > > Hopefully the above helped :) > > Partially, let's consider an initial startup where Prepare is called > (and I assume we don't call either virHostdevReattachPCIDevice or > virHostdevPCINodeDeviceDetach yet). > > So how does this code check if the device has been manually detached > from the host? Step 1 doesn't add to the inactiveList and step 2 only > adds managed devices. How would that lookaside element be on the > inactiveList - what put it there? > > Is there some magic w/ virHostdevPCINodeDeviceDetach that I'm missing? Oh, I see what you mean now! The long and short of it is that the new code simply doesn't handle the situation you're describing :) I wonder what's the proper way to handle this. The way it worked before was *way* implicit, and the less implicit stuff we have, the better. I guess checking the driver the device is bound to, and adding it to the inactive list if it's one of the known stub drivers would do the trick for now. Does that sound reasonable? I'll try and cobble together an implementation. Long term, as I mentioned in the past, we should implement a way for the active and inactive list to be stored to disk and read back at startup time, ensuring all information are preserved across daemon restarts. I'd like to work on that as a follow-up enhancement, though. For now, creating a solid base to work on (while avoiding regressions) should be the main focus. Thanks for catching this! -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list