2:22 a.m.
Cc'ing a few QOMmers...
Laine Stump <laine(a)redhat.com> writes:
Now that qemu is getting the q35 machine type, libvirt needs to
support it.
As far as I understand, from libvirt's point of view, q35 is just
another x86_64 system, but with a different set of implicit devices,
and possibly some extra rules limiting which devices can be plugged
into which bus/slot on the guest. That means that in order to support
it, we will need to recognize when a q35-based machine type is being
created, and auto-add all the implicit devices to libvirt's config
model for that domain, then pay attention to the extra rules when
assigning addresses for all the user-added devices.
We already add implicit controllers/devices for pc-based machine
types; as a matter of fact, currently, libvirt improperly assumes (for
the purposes of adding implicit devices) that *every* virtual machine
is based on the "pc" machine type (or rather it just doesn't pay
attention), so it always adds all the implicit devices for a pc
machine type for every domain. This of course is already incorrect for
many (probably all?) non-x86 machine types, even before we add q35
into the mix. To fix this, it might be reasonable (and arguably, it's
necessary to fix the problem in a backward-compatible manner) to just
setup a table of machinetype ==> implicit device lists, look up the
machine type in this table, and add the devices needed for that
machine type. This goes against libvirt's longstanding view of
machinetype as being an opaque value that it merely passes through to
qemu, but it's manageable for the existing machine types (even
including q35), since it's a finite set. But it starts to be a pain to
maintain when you think about future additions - yet another case
where new functionality in qemu will require an update to libvirt
before it can be fully used via libvirt.
In the long term, it would be very useful / more easily maintainable
to have a qemu status command available via QMP which would return the
list of implicit devices (and their PCI addresses) for any requested
machine type.
You want to ask QEMU to describe the "board", i.e. the machine without
any optional devices.
The way you can do that now is to create a machine without any optional
devices, then introspect.
Introspection tools:
* info qtree (HMP only)
Mentioned for completeness. You really want QMP here.
* qom-list and qom-get (QMP only)
These let you examine QOM as attributed graph.
Non-qdevified devices are invisible. Show stopper only when this
includes devices libvirt needs to know about. For instance, a
mandatory device can be safely ignored as long as its resources cannot
conflict with anything libvirt might want to plug in.
Ceterum censeo we need full qdevification
It would be necessary that this command be callable
multiple times within a single execution of qemu, giving it a
different machinetype each time.
This isn't feasible without major surgery, as far as I can tell.
This way libvirt could first query
the list of available machinetypes in this particular qemu binary,
then request the list of implicit devices for each machine type
(libvirt runs each available qemu binary *once* the first time it's
requested, and caches all such capabilities information so that it
doesn't need to re-run qemu again and again). My limited understanding
of qemu's code is that qemu itself doesn't have a table of this
information as data, but instead has lines of code that are executed
to create it, thus making it impractical to provide the list of
devices for a machinetype without actually instantiating a machine of
that type. What's the feasibility of adding such a capability (and in
the process likely making the list of implicit devices in qemu itself
table/data driven rather than constructed with lines of code).
Machines are created by ad hoc board setup code. This code is generally
written to run once. And by once I mean one board gets initialized
once, and never destroyed. To support destruction, we'd have to find
out what needs to be cleaned up (allocated resources, global state,
...), and clean it up. For all of the boards. Even the barely
maintained ones.
Let's take a step back from the swamp we're in and examine the
swamp^H^H^H^H^Hmeadow we're trying to reach.
qdev used to be "declarative" in the sense that device models and their
properties are declared by data. Easy to introspect. The (far away)
goal was to extend this so that machine types become data, too.
QOM isn't declarative, it's fully dynamic, i.e. classes and properties
are created by code. I never quite understood why, but I'm sure there
are good reasons. I suspect the goal of having machine types as data
has been dropped, and the new plan is to create machines for
introspection. Assumes creating and destroying machines won't be a big
deal once they're fully QOMified.
More questions:
Alex replied to these, and I have nothing to add.