Re: [Qemu-devel] [PATCH 0/3] add hotplug opt-out option for devices.

[Markus Armbruster]

Gerd Hoffmann <address@hidden> 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?