On Wed, Jan 27, 2021 at 03:24:26PM +0100, Michal Privoznik wrote: > On 1/27/21 11:54 AM, Daniel P. Berrangé wrote: > > On Wed, Jan 27, 2021 at 10:45:11AM +0000, Daniel P. Berrangé wrote: > > > On Thu, Jan 21, 2021 at 11:15:04AM -0500, Igor Mammedov wrote: > > > > > > > > How does a mgmt app know which machine types need to use this > > > option ? The machine type names are opaque strings, and apps > > > must not attempt to parse or interpret the version number > > > inside the machine type name, as they can be changed by > > > distros. IOW, saying to use it for machine types 4.0 and > > > older isn't a valid usage strategy IMHO. > > > > Looking at the libvirt patch, we do indeed use his property > > unconditionally for all machine types, precisely because parsing > > version numbers from the machine type is not allowed. > > > > https://www.redhat.com/archives/libvir-list/2021-January/msg00633.html > > > > So this doc is telling apps to do something that isn't viable > > The other approach that I was suggesting was, that QEMU stops reporting > 'default-ram-id' for affected machine types. The way the switch from '-m > XMB' to memory-backend-* was implemented in libvirt is that if libvirt sees > 'default-ram-id' attribute for given machine type it uses memory-backend-* > otherwise it falls back to -m. > > Since we know which machine types are "broken", we can stop reporting the > attribute and thus stop tickling this bug. I agree that it puts more burden > on distro maintainers to backport the change, but I think it's acceptable > risk.
IIUC That's only a burden for distros if they're creating their own machine types, in which case they've already decided the burden is a net win. 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 :|
