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 instant!
iating 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?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list