On Tue, Aug 17, 2010 at 11:37:34PM +0200, Jiri Denemark wrote: > > > The hash iterator visits in an unpredictable order. It shouldn't matter > > > because for this usage, all that is important is that 'nextslot' eventually > > > ends up with the largest slot ID + 1. > > > > We don't want the first unused slot, rather the last slot reservation > > that was in place before the reconnect (often the first unused slot if > > you haven't done a lot of hot-unplugging, but not necessarily the case). > > The only way I can see to get at this is to revisit the reservations in > > the same order as they were reserved, rather than in the random order > > Actually, thinking about it you are right that setting nextslot to the largest > slot used + 1 is not always correct. Even when no PCI devices are > added/removed after a guest is started, nextslot doesn't have to look like > that. E.g., if there is a device with explicit PCI address 0:0:31 in the XML. > Although in normal configurations it would work. > > However, if we start thinking about hot(un)plugging PCI devices, even your > suggestion of revisiting reservations in the original order wouldn't help much > since the last device which influenced nextslot value might have been already > unplugged from the guest. The only solution which really updates nextslot to > exactly the same value it had before restarting libvirt is storing it in the > runtime XML inside <domstatus>, from where it can be just read when the domain > is being reconnected. 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. Worst case, the first PCI hotplug needs to do an O(N) loop over PCI devices to find an unused one, thereafter all the hotplug ops will be back to O(1) because nextslot will be set again. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list