qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/11 v3] Refactor PCI/SHPC/PCIE hotplug to use


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 00/11 v3] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API
Date: Wed, 18 Dec 2013 16:59:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 18/12/2013 16:48, Igor Mammedov ha scritto:
>> Hotplugging a device is a special case of plugging a device.  If a bus
>> or device only supports cold-plug, that can be done using
>> "bc->allow_hotplug = false" or "dc->hotpluggable = false".
> Do we need per instance ability to set "hotpluggable" property?
> For example board might want to mark some CPUs as not hotpluggable.

I think such fine-grained control could be handled from dc->unplug.
Let's not do anything more than we need, until we need it.

Right now, all we need to model is the fact that a device X can act as
hotplug controller for multiple buses, X is not the parent of those
buses, and we need to tell those buses about X.  This is hotplug-handler
in BusState.

We also like to distinguish devices that only support -device (or are
even only board-instantiatable) from devices that support device_add.
This is dc->hotpluggable.  It is not absolutely necessary, but it makes
sense if "plugging" gets a more central place in qdev.  This is the case
after you add hotplug-handler.

>>> Interfaces would be another option too.
>>
>> Interfaces are fine, but the question is who finds them and calls them.
>> In this case, the discovery mechanism is a link property, and the
>> calling mechanism is an explicit hook in the "realized" property.
>
> If we don't need per instance "hotpluggable" state and we can call
> interfaces from generic qdev/device code, then we would need at first
> only TYPE_HOTPLUGGABLE_BUS_DEVICE_IF and later for link<> based hotplug
> we could add just TYPE_HOTPLUGGABLE_DEVICE_IF. Difference would be in
> the way they get access to hotplug device link, former one will use bus
> for it and second some other way.

I think this is overengineered.  What you have is flexible and decently
clean.  I don't think there's any need to go from the device to the bus
and from there optionally to the handler.  Most of the time you couldn't
do anything really in the bus, you would have to call some sort of
bus-specific callback (like SCSIBusInfo).  It is then equivalent to set
the bus's parent device as a (hot)plug handler and go straight from the
device to the handler, as in your patches.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]