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 :|