On 08/02/2010 07:31 AM, Jiri Denemark wrote: >> Don't we still want to start from the last slot, and wrap around the >> search only when we reach the end, rather than always starting from 0? >> I'm thinking particularly about compatibility with older qemu, where >> always starting from 0 risks interleaving new assignments among the >> pre-assigned slots, and may end up allocating slots in a way that throws >> off Windows. Or am I worried about a non-issue? > > TBH I don't know. If qemu can get upset about it, we probably can't change the > logic at all. Or at the best we can have it variable depending on qemu > version. So if someone knows better if we can safely change this or not, that > would be great. (too bad Daniel is on vacation) > > Anyway, going from the nextslot and wrapping wouldn't really help with this > situation. It would only postpone the possible compatibility issues until > nextslot wraps around. Well, my understanding is that older qemu didn't allow specifying specific slots, so they only assigned slots in sequential order. The moment you request a particular slot, you are already depending on newer qemu. But we also just checked in several patches recently to pre-assign several slots, so that we match the same default assignment as older qemu. If those pre-assignments contain gaps, but we start from 0 on every search, then we will fill in those gaps, where the old code used to put additional slots beyond the last pre-assigned gap. And since Windows is sensitive to the case where pci devices have changed slots from the previous boot, you can see where my question was coming from. Also remember that with those older qemu, since you can't request a specific slot, you would have already had a problem with consecutively populating all available slots if you ever get to the end where wraparound would even be considered. It's only with newer qemu, where you can request a specific slot but in so doing create a huge gap, where wraparound proves useful. -- 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