Add option to skip cpu feature and model verification in libvirt and rely on qemu 'enforce' option

[Jiri Denemark]

On Wed, Nov 23, 2022 at 13:35:42 +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). If I'm reading your
> email right, you're saying that libvirt is (trying to?) move in a direction
> where instead of having say src/cpu_map/x86_Icelake-Client.xml

That's mostly where I hope we can get. I'd love to see CPU models being
probed dynamically from QEMU. And especially the details of each CPU
models, i.e., what features it's going to enable. Well, for proper host
CPU detection we will still most likely need to have a mapping between
CPU signatures and models, but this is unrelated to the issue we're
discussing in the thread.

> instead there is a very minimal layer that knows that some qemu
> feature got renamed, and is effectively just a filter "papering over"
> such qemu issues.

This depends on what you mean by a very minimal layer :-) See below...

> And in particular it's no longer the case that every single cpu model,
> cpu model version (needs commits to both qemu and libvirt)

Yes, I hope so.

> and cpu feature needs commits to both qemu and libvirt

No, libvirt will still need each CPU feature to be added explicitly. But
this is pretty much a non issue. Defining a new feature is fast and
simple (well, unless Intel invents yet another way of advertising
supported features) and the features never change.

> and they must be in sync.

Features need to be in sync, but CPU models do not (and of course,
there's even nothing to sync if we probe the definition in runtime).

> I'm presuming this will also mean plumbing through qemu model versions
> too, as that's an essential part I think.

Right.

Jirka