Cc'ing a few QOMmers... Laine Stump <laine@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list