On Thu, Dec 11, 2025 at 09:48:32AM +0000, Daniel P. Berrangé wrote: > The appealing thing about machine types is that it is an opaque > collection of properties. The mgmt app does not need to know about > any of the properties being set, it can just let the machine type > do its magic. > > Probing values for individual features which are supported on a host > means mgmt apps need to be made aware of all the properties that are > affected, and keep track of them for the life of the VM. This is a > significantly higher burden for the mgmt app to deal with that the > opaque collection machine types define, especially because apps won't > know ahead of time which objects/properties might need this facility > in future.
Yes, exactly. IMHO we may still need "probing" of host features at some point, but we do have two completely different way to stable the guest ABI: (a) Machine types (like now) (b) "probing" + "QMP set()s" Here "QMP set()s" can be QMP updating a property of an object, or something like what Vladimir proposed in the other virtio-net/tap series, via a separate new QMP command. Solution (b) has a major benefit of high flexibility - we do not need machine type versioning anymore (hence, we still need "q35", but not "q35-X.Y" etc.), because any QEMU can likely migrate to almost any QEMU: mgmt will probe both sides and apply mini subset for both sides, no matter how old it was. To pay that off, mgmt needs to know every single trivial detail of QEMU change on every single device to make migration work. When new things introduced to QEMU, it must be OFF, then mgmt turns it on until probing both sides have it. That makes solution (b) less appealing. The other thing is, since we stick with solution (a) for all these years, IMHO we should either stick with it, or if we really think (b) is better we should gradually obsolete (a) and use (b) all over. I just don't see it coming, though.. as (a) is still working almost perfect - it enables feature slower only until a new machine type used (normally means a VM cold reboot), but it hides too many trivial details mgmt doesn't need to care, hence much less work needed. IMHO we should be careful on making both (a)+(b) available (again, for (b) the probing is still fine, it's about offloading things to mgmt to set() via QMPs). If so, it likely implies we didn't think all things through. Thanks, -- Peter Xu
