[libvirt PATCH 10/11] domain_capabilities: Add blockers attribute for CPU models

[Daniel P. Berrangé]

On Tue, Oct 04, 2022 at 04:28:53PM +0200, Jiri Denemark wrote:
> We already show whether a specific CPU model is usable on the current
> host without modification via the 'usable' attribute of each CPU model.
> But it may be useful to actually see what features are blocking each CPU
> model from being usable. Especially when we already fetch the info from
> QEMU and propagating it to domain capabilities XML is all we need to do.

> diff --git a/tests/domaincapsdata/qemu_4.2.0-q35.x86_64.xml b/tests/domaincapsdata/qemu_4.2.0-q35.x86_64.xml
> index dab12e5888..8ca9e8d2b2 100644
> --- a/tests/domaincapsdata/qemu_4.2.0-q35.x86_64.xml
> +++ b/tests/domaincapsdata/qemu_4.2.0-q35.x86_64.xml
> @@ -63,7 +63,7 @@
>      <mode name='custom' supported='yes'>
>        <model usable='yes' vendor='unknown'>qemu64</model>
>        <model usable='yes' vendor='unknown'>qemu32</model>
> -      <model usable='no' vendor='AMD'>phenom</model>
> +      <model usable='no' vendor='AMD' blockers='mmxext,fxsr_opt,3dnowext,3dnow,sse4a,npt'>phenom</model>

This is an XML design anti-pattern, because it invents a data format
inside the attribute which the caller then has to further parse.

If we want to expose this, it needs to be with child elements IMHO,
but yes it will be more much more verbose.


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 :|