On Thu, Dec 11, 2025 at 03:26:13PM +0000, Daniel P. Berrangé wrote: > On Thu, Dec 11, 2025 at 10:09:16AM -0500, Peter Xu wrote: > > 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. > > I don't believe that probing could ever be a placement for (a). Determining > what you want to use is not a decision that can be made in isolation of > the current host. You need to know the capabilities of hosts that you > intend to be able to migrate to. > > Machine type versions facilitate this as an admin can express the > compatibility constraint in terms of this high level opaque definition, > and not have to understand 100's of properties and their supportability > across many hosts. > > The same applies to non-guest host compatibility settings. I might be > runing on a RHEL-9.6 host, but I want to have compatibility with any > RHEL-9.2 host or newer. I can't probe QEMU on the 9.6 host to determine > what is acceptable for 9.2. We need to be able to express that cross > host compatibility as an admin, without having to list a huge set of > individual properties.
Yes, maybe I didn't explain myself clearly, I believe we share the view. My point was we shouldn't introduce special QMP commands to do set()s just to work similiarly as what machine versioning / compat properties do. I hope we will start to have something like query-platform soon. Jason and Michael have some discussion here, which should be discussing similar concept: https://lore.kernel.org/all/CACGkMEtdxWJygVbcuvER5yj13R0JL_bxPSAg0eYyiBeh=sy...@mail.gmail.com/ Maybe USO can be a start point for us doing this, allowing mgmt to probe host features. Thanks, -- Peter Xu
