[libvirt] [PATCH 2/2] qemu: Update next usable PCI slot on domain reconnect

[Eric Blake]

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 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/20100819/ce547496/attachment-0001.sig>