[libvirt] [PATCH] qemu: Fix PCI address allocation

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100802/d64e4eb7/attachment-0001.sig>