|
From: | Damien Hedde |
Subject: | Re: [RFC PATCH v5 0/3] Sysbus device generic QAPI plug support |
Date: | Wed, 25 May 2022 15:32:19 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |