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

Daniel P. Berrangé berrange at redhat.com
Tue Oct 4 19:51:21 UTC 2022


On Tue, Oct 04, 2022 at 07:35:31PM +0200, Jiri Denemark wrote:
> On Tue, Oct 04, 2022 at 17:34:34 +0100, Daniel P. Berrangé wrote:
> > 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.
> 
> You're absolutely right, but that's the only option we have I'm afraid.
> Mixing subelements and text nodes is a much worse anti-pattern. I wish
> the model name was in an attribute, but it isn't and having
> 
>     <model usable='no' vendor='AMD'>
>       <blocker name='mmxext'/>
>       phenom
>     </model>
> 
> is just insane :-(

True, I wonder if there's a different approach to the overall problem
that would be better.

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


More information about the libvir-list mailing list