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

[Peter Maydell]

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.

> 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.

-- PMM