On 08/18/2010 05:26 AM, Daniel P. Berrange wrote: > On Wed, Aug 18, 2010 at 01:15:55PM +0200, Jiri Denemark wrote: >>> Why do we need it to be exactly the same value ? nextslot is just an >>> efficiency optimization isn't it. ie, so instead of starting from >>> slot 0 and iterating over 'N' already used slots till we find a free >>> slot, we can get the next free slot in 1 step. As such do we really >>> need to worry about restoring it to the same value after restarting >>> libvirtd. >> >> That was my understanding too. But Eric was concerned (in an older thread) >> about hotplugging PCI devices in a nonmonotonic way. He thinks it could upset >> Windows guests. Of course, if nextslot ever wraps from >> QEMU_PCI_ADDRESS_LAST_SLOT back to zero, such guests would be doomed anyway so >> we are only a bit nicer to them. I don't know if this is a real issue or not >> since I haven't met a Windows guest which I'd like to hotplug a PCI device in. > > There's no requirement to plug devices in ascending slot order - we can > have gaps at will with any ordering. At this point, I'm starting to think that we can just drop this 2/2 patch and not worry about nextslot being stable across libvirtd restarts. My original concern was for a windows vm created against an older qemu, with no hot-plugging support, then being updated to a newer libvirt: there, nextslot must be incremented in the same order when firing up the vm from XML so that windows won't complain. But that only affects start-up; once the guest is up and running, nextslot only matters for hotplugged slots, and based on my problem definition, this was for a VM defined in the days before hotplug support being ported to newer underlying tools. Even if nextslot is reset to 0 after a libvirtd restart, that should only have an impact on future hot-plugged devices, and not any of the original devices reserved by the xml. And if windows can already handle hot-plugging, then it shouldn't matter which device slot a hot-plug occurs on; even if it is a different slot after the libvirtd restart than it would have been if libvirtd had been constantly running. If anyone can prove us wrong with an actual bug report, we can deal with the issue then. But for now, let's just drop this as over-engineering a solution for a non-problem. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list