Gerd Hoffmann <kra...@redhat.com> writes: >> I understand why you're adding this but this is one of those horrible >> abuses of qdev that we really need to avoid. >> >> There are two valid reasons why hotplug is not possible: >> >> 1) Hotplugging is not supported by the *slot*. This is something that >> needs to be exposes through ACPI. This is not a qdev property, but a >> property of a PCI slot. > > Well, yea, right. Sort of. The ACPI thing applies to some of the > slots only. But, yes, strictly speaking this is a slot not a device > property in the case of PCI. Problem is qemu doesn't really has an > idea what a pci slot is ...
Needs fixing. Can't see how we can get sane hot plug without a proper representation of PCI slots in QEMU. >> It's very important that we do this correctly >> because Windows puts a little icon in the systray that advertises >> quick-removal of devices in slots that support hotplug. > > Indeed. > >> 2) The PCI device is soldered to the MB or is otherwise not part of a >> PCI slot. Again, this is part of the ACPI definition. > > (3) The qemu emulation can't handle hot-unplug. > >> Since the PIIX3 lives in slot 1, our ACPI tables should not advertise >> slot 0 or slot 1 as supporting hotplug. > > They do currently. Should be easily fixable. > >> Hotplug information has no business being part of the core qdev >> structures. Hotplug is a PCI concept and the information needs to live >> at the PCI layer to be meaningfully. > > Wrong. PCI certainly isn't the only bus which supports hotplug. It > *does* make sense to handle generic hotplug stuff at qdev level. Could the proper place be qbus instead of qdev? >> An ideal interface would explicitly allow a user to mark a series of PCI >> slots as no supporting hotplug. It would be convenient in order to >> ensure that your virtio-net wasn't accidentally ejected by a click-happy >> Windows user. > > Indeed. That one is a bit harder I suspect. Can this be done without > generating acpi tables dynamically?