[Qemu-devel] q35 machine type and libvirt.

[Laine Stump]

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

More questions:

1) It seems that the exact list of devices for the basic q35 machine type 
hasn't been settled on yet, is that correct?

2) Are there other issues aside from implicit controller devices I need to 
consider for q35? For example, are there any devices that (as I recall is the 
case for some devices on "pc") may or may not be present, but if they are 
present they are always at a particular PCI address (meaning that address must 
be reserved)? I've also just learned that certain types of PCIe devices must be 
plugged into certain locations on the guest bus? ("root complex" devices - is 
there a good source of background info to learn the meaning of terms like that, 
and the rules of engagement? libvirt will need to know/follow these rules.)

3) What new types of devices/controllers must be supported for a properly 
functioning q35 machine?