Hi Dimitri, On 12:18 Fri 28 Mar , Dimitris Aragiorgis wrote: > So from what I understand the proposed change will: > > 1) affect only virtio devices (NICs, and Disks) > 2) keep the current hotplug rational (only NodeD knows about PCI info) > 3) will change _DEFAULT_PCI_RESERVATIONS and reserve the first 8 slots > 4) run `info pci` to get current PCI status and find available slots > and "OR" them with _DEFAULT_PCI_RESERVATIONS > 5) revert the commit that fixes #757 in the sense that virtio balloon > and spice wont get PCI info. > > If I don't miss anything here, I agree with all the above. So yes, > please proceed with patches. > > Just one note here: > > Currently *only* virtio devices obtain PCI info and thus are > hotplug-able. Primarily, Ganeti used only the `-drive` option for disks. > Hotplug support added the `-device` option, so that they can obtain PCI > info. Should we adopt the `-device` option to all devices? Would this > make any sense?
Personally, I see no reason to bind hotplugging to PCI-only devices. Both, plain SCSI and Virtio SCSI support disk hotplugging for instance and do not need a PCI slot for each disk (they hot-plug disks onto the SCSI bus). I think what is actually needed to store in the runtime is the unique device hotplug id (which can be anything as far as I understand), and not a PCI slot specifically. I started implementing virtio SCSI yesterday and hit upon this, so this also has to be changed. I think the rationale there would be to have two distinct functions: PCI device hotplugging and drive hotplugging (`device_add' and `drive_add' in qemu terms). Virtio-blk disks currently need both, a disk hotplug and a PCI hotplug. NIC hotplugging needs only PCI hotplug and (virtio-)SCSI needs only a disk hotplug¹. Currently these two functions are interleaved and depend on a PCI slot being available to encode in the id, but it shouldn't be too difficult to factor that out. I'll have a look at this as well. ¹ Note that even virtio-scsi uses the -device syntax with the scsi-hd driver, but does not yield back a PCI device. So `-device` does not necessarily imply a PCI slot is available. And a small question re: PCI slot reassignment: from your tests at GRNET, do you happen to know what is the threshold of moving PCI devices around that will trigger a re-activation in Windows? Regards, Apollon
