Re: [PATCH v2 00/21] qom: introduce property flags to track external user input

[Peter Krempa <pkrempa@redhat.com>]

On Wed, Mar 11, 2026 at 13:14:41 +0000, Daniel P. Berrangé via Devel wrote:
> On Wed, Mar 11, 2026 at 02:05:24PM +0100, Markus Armbruster wrote:

[...]

> For -object / object_add  we introduced formal QAPI modelling of
> all Object subclasses which implement the UserCreatable interface.
> IIUC, that gives us the desired separation between internal and
> external views, as only properties declared in qapi/qom.json are
> publically settable.
> 
> This work did not apply to the Device classes because the historical
> baggage with qdev being grafted onto qom, means we don't have that
> working via the UserCreatable inteface or -object/object_add.
> 
> Can we bring Device into the same world though ?
> 
> Adding 1000 device types to QAPI is a huge job, so it would need to
> be a long incremental job, unless perhaps we auto-generate QAPI
> descriptions for everything that already exists ?

When I was converting libvirt to use the JSON syntax for -device I've
used the output of -device DEVTYPE,? to figure out the required types.
From what I've observed, in the vast majority of casesthe type that
qemu wants is already reported, thus generating the schema for it should
be feasible.

Obviously majority of the options lack any form of description so
documentation would be a much bigger problem, but there would be already
an starting point.

Anyways for anyone wanting to actually do this libvirt's qemuxmlconftest
suite could be useful here as it contains a sizable portion of options
libvirt supports (I'ts extremely likely that we don't cover some corner
cases though). In addition the testsuite can actually perform
validation of any of the commands taking JSON against the monitor schema,

To validate that everything that libvirt covers by tests is present in
the schema for 'device_add' one would need to just change 1 boolean (to
force full schema validation for device_add) and add a schema dump.