qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] qdev: Mark devices as non-hotpluggable by de


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2] qdev: Mark devices as non-hotpluggable by default
Date: Tue, 26 Sep 2017 19:00:17 +0100

On 26 September 2017 at 18:27, Thomas Huth <address@hidden> wrote:
> On 25.09.2017 19:59, Eduardo Habkost wrote:
>> On Mon, Sep 25, 2017 at 07:42:13PM +0200, Thomas Huth wrote:
>> "make check" found a few candidates:
>> https://travis-ci.org/ehabkost/qemu/jobs/278743999
>>
>>   Initialization of device dpcd failed: Device 'dpcd' does not support 
>> hotplugging
>> [...]
>>   Initialization of device nand failed: Device 'nand' does not support 
>> hotplugging
>
> I've now had a look at those, and I now feel like the whole
> "hotpluggable = false by default" idea was either just wrong or there
> are other smart ideas necessary to solve this issue: These devices are
> created during the instance_init() function of another device, e.g.
> "dpcd" is created in the xlnx_dp_init() function, which is the
> instance_init of TYPE_XLNX_DP. Now, instance_init() can be called at any
> time during runtime, even without really adding the device, e.g. for
> parameter introspection (try "device_add xlnx.v-dp,help" at the HMP
> prompt for example).

This is a bit weird though, because it means we have a lot of devices
which are "it's OK to instance_init this but not to actually create
(realize) it". I don't think that that should count as hotpluggable.
(Is it actually useful to be able to call "help" for a device
that it is not possible to create?)

> But just setting "hotpluggable = true" for a device (e.g. "dpcd") which
> could be created during instance_init also does not sound very
> attractive to me... Not sure about any good alternative way to tackle
> this right now, maybe I've eventually got to check user_creatable in
> device_set_realized, too, or move the hotpluggable checks to
> qmp_device_add() instead... I'll think about that for a while...
> suggestions welcome!

I think the general principle of defaulting to "you need to
specifically mark the device if you want it to be permitted to
hotplug it" seems right -- even devices which are created under
the hood by the real hotpluggable device still need to be
written to support it (ie by having a finalize method or
whatever to clean up). So they should probably be marked as
"hotpluggable but not user createable" or similar.

We just need to get the details right.

thanks
-- PMM



reply via email to

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