Am 09.12.2025 um 17:28 hat Peter Xu geschrieben: > [This is an RFC series, as being marked out. It is trying to collect > opinions. It's not for merging yet] > > Background > ========== > > It all starts with machine compat properties.. > > Machine compat properties are the major weapon we use currently in QEMU to > define a proper guest ABI, so that whenever we migration a VM instance from > whatever QEMU version1 to another QEMU version2, as long as the machine > type is the same, logically the ABI is guaranteed, and migration should > succeed. If it didn't, it's a bug. > > These compat properties are only attached to qdev for now. It almost > worked. > > Said that, it's also not true - we already have non-qdev users of such, by > explicitly code it up to apply the compat fields. Please refer to the > first patch commit message for details (meanwhile latter patches will > convert them into a generic model). > > Obviously, we have demands to leverage machine compat properties even > outside of qdev. It can be a network backend, it can be an object (for > example, memory backends), it can be a migration object, and more.
This doesn't feel obvious to me at all. A machine type defines what hardware the guest sees. Guest hardware is essentially qdev. I don't see any reasons why a backend should be interested in what guest hardware looks like, that would seem like a bad layering violation. Many backends can even exist without a guest at all, and are also used in tools like qemu-storage-daemon. Having a machine type in a tool that doesn't run a guest doesn't make any sense. So if we do introduce some mechanism to provide different defaults for compatibility with older versions, it has to be separate from machine types. Maybe it would make most sense to address this on the QAPI level then and finally fully QAPIfy the command line. Adding defaults to the QAPI schema is something that has come up again and again, so maybe we could introduce that and do it in a versioned way from the start. Kevin
