On Thu, Aug 01, 2024 at 11:15:47AM -0400, Michael S. Tsirkin wrote: > On Thu, Aug 01, 2024 at 11:13:37AM -0400, Peter Xu wrote: > > Do we really concern about users not enabling features that much? I > > thought users always can manually change the XML and add whatever they > > need, and device properties do not like too special here to me. I mean, we > > have bunch of "features" exported as new "-devices" and users must opt-in > > for them by changing the XML. We never worried on user not using them. I > > doubt whether we worried too much on user not opt-in, especially for > > performance features, because they're, IMHO, targeting advanced users. > > What I do not like, is pushing the knowledge of what good defaults > are to libvirt. With the -platform concept, libvirt wouldn't need to know anything about the settings being used, nor the defaults. Consider how it works for machine types. Libvirt queries the machine types, and gets a list back, and QEMU expresses a default. eg saying that 'pc-i440fx-9.1.0' is aliased to 'pc'. So libvirt can expand 'pc' to a particular version that QEMU has chosen as the default. Conceptually I could see something similar working for the -platform concept. Libvirt would ask QEMU for all the "platform" variants that are available on the current running kernel. QEMU can reply with the list, and indicate which of those is the "newest" in some manner. Absent any preference from the mgmt app, libvirt would use whichever one QEMU indicates was the newest. This optimizes for best featureset on the current kernel, as the cost of possibly reduced migration compatibility. When a mgmt app is caring about migration, they would explicitly tell libvirt which platform version to use, just as they would explicitly ask for a specific machine type version, rather than accepting the 'pc' default. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
