Re: Add option to skip cpu feature and model verification in libvirt and rely on qemu 'enforce' option
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 :|