Re: [RFC PATCH v5 0/3] Sysbus device generic QAPI plug support

[Damien Hedde <damien.hedde@greensocs.com>]

On 5/25/22 13:45, Peter Maydell wrote:
> On Wed, 25 May 2022 at 10:51, Damien Hedde <damien.hedde@greensocs.com> wrote:
>> On 5/24/22 19:44, Mark Cave-Ayland wrote:
>>> Sorry for coming late into this series, however one of the things I've
>>> been thinking about a lot recently is that with the advent of QOM and
>>> qdev, is there really any distinction between TYPE_DEVICE and
>>> TYPE_SYS_BUS_DEVICE anymore, and whether it makes sense to keep
>>> TYPE_SYS_BUS_DEVICE long term.
>>
>> On QAPI/CLI level there is a huge difference since TYPE_SYS_BUS_DEVICE
>> is the only subtype of TYPE_DEVICE which is subject to special
>> treatment. It prevents to plug a sysbus device which has not be allowed
>> by code and that's what I want to get rid of (or workaround by allowing
>> all of them).
> 
> Yes, but the fact that TYPE_SYS_BUS_DEVICE is a special subclass
> is an accident of history. At some point we really ought to tidy
> this up so that any TYPE_DEVICE can have MMIO regions and IRQs,
> and get rid of the subclass entirely. This isn't trivial, for
> reasons including problems with reset handling, but I would
> prefer it if we didn't bake "sysbus is special" into places like
> the QMP commands.
> 
> More generally, I don't think that the correct answer to "is this
> device OK to cold-plug via commandline and QMP is "is it a sysbus
> device?". I don't know what the right way to identify cold-pluggable
> devices is but I suspect it needs to be more complicated.

"sysbus is special" is already into the QMP commands.

Right now, any user-creatable device (but sysbus devices) can be 
cold-plugged by CLI using "-device".
The checks are basically:
+ does this device is "user-creatable" ?
+ do realize succeed ? (check device properties and handle bus connection)
So basically this is down to the bus realize mechanism to deal with any 
non-trivial constraint.

Concretely "user-creatable" means cold-pluggable by CLI.
And the reason why it cannot be done by QMP is because QMP commands are 
not possible at that time (the based-on series fix that).

For sysbus device, it is the same but there is an additional check to 
verify that the device is present in the machine allow list.

> 
>> I'm note sure what you mean by identification and enumeration. I do not
>> do any introspection and rely on knowing which mmio or irq index
>> corresponds to what. The "id" in `device_add` allows to reference the
>> device in following commands.
> 
> This is then baking in a device's choices of MMIO region
> ordering and arrangement and its IRQ numbering into a
> user-facing ABI. I can't say I'm very keen on that -- it
> would block us from being able to do a variety of
> refactorings and cleanups.
>

It's the same for any device property, we make a choice that is exposed 
to the user.

Whether this is done at TYPE_DEVICE or TYPE_SYS_BUS_DEVICE level does 
not change anything to that matter. We could, for example, choose to 
follow the order/name convention used in device tree specs if the issue 
is having no rules. That would probably ease any fdt generation from a 
device qemu model.

That does not prevent us to make change after. Right now, this would be 
accessible only if using the _none_ machine and with '-preconfig' 
experimental and using the _none_ machine. So I don't think we have to 
follow some deprecation policy.

What would you consider a starting point to allow that kind of plug ?

--
Damien