On Wed, Nov 23, 2022 at 01:35:42PM +0000, John Levon wrote: > On Wed, Nov 23, 2022 at 02:12:59PM +0100, Jiri Denemark wrote: > > > Not to mention that QEMU changed names of several features and even deprecated > > the old spellings which is completely transparent to libvirt users as they can > > still use the old names no matter what version of QEMU they use. This is one > > of the key benefits of libvirt. > > It's certainly very unfortunate that qemu did that (and we are still paying the > price for the arch-facilities/arch-capabilities thing). Note, it depends on your POV of 'unfortunate'. Of course any time QEMU changes something, it has an impact on things using QEMU, but libvirt is here precisely to give isolation from those changes. Indeed, the very fact that libvirt exists and is widely used, is what allows QEMU to deprecated and rename stuff on a pretty aggressive schedule. If libvirt wasn't providing this isolation, then it is unlikely QEMU would have adopted its 2 release deprecated cycle, and would be locked into their mistakes for a much longer period. IOW, libvirt is allowing QEMU to fix their own technical debt on a more aggressive timeframe, albeit at some cost to libvirt maintainers. > And in particular it's no longer the case that every single cpu model, cpu model > version, and cpu feature needs commits to both qemu and libvirt, and they must > be in sync. I would *always* expect there to be libvirt work to define the CPU feature names, and possibly CPU model names. IIUC, we don't need to copy over the entire CPU model expansion though, since we can query that direct from QEMU given the model name. 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 :|
