Re: [libvirt] [PATCH 2/2] qemu: Update next usable PCI slot on domain reconnect
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)