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
