[libvirt] [PATCH 3/3] qemu: Adapt to changed ppc64 CPU model names

Jiri Denemark jdenemar at redhat.com
Tue May 22 13:46:52 UTC 2018


On Tue, May 22, 2018 at 11:02:17 +0200, Andrea Bolognani wrote:
> On Thu, 2018-05-17 at 17:33 +0200, Jiri Denemark wrote:
> [...]
> > --- a/tests/domaincapsschemadata/qemu_2.12.0.ppc64.xml
> > +++ b/tests/domaincapsschemadata/qemu_2.12.0.ppc64.xml
> > @@ -25,7 +25,11 @@
> >      <mode name='host-model' supported='yes'>
> >        <model fallback='allow'>POWER8</model>
> >      </mode>
> 
> This is quite suspicious - it looks like a proper CPU model, but
> it's really a compatibility mode, so it should be lowercase rather
> than uppercase. You certainly won't be able to use
> 
>   <cpu mode='host-model>
>     <model>POWER8</model>
>   </cpu>
> 
> so why are we advertising the uppercase variant here? Am I missing
> something?

Hmm, you're right. In general, this is advertising the host CPU (ideally
as seen by QEMU), which doesn't really work for ppc since host-model was
misused for compatibility modes. I think we'll have to add a special
hack to produce <mode name='host-model' supported='yes'/> without
showing any CPU model. Ideally, we would somehow list all supported
compatibility modes, but this can be left for the future.

> > -    <mode name='custom' supported='no'/>
> > +    <mode name='custom' supported='yes'>
> > +      <model usable='unknown'>POWER9</model>
> > +      <model usable='unknown'>POWER8</model>
> > +      <model usable='unknown'>POWER7</model>
> > +    </mode>
> 
> This is of course an improvement, but I'm not sure we want to keep
> exposing uppercase model names to users.
> 
> I understand we need to keep accepting them for compatibility
> reasons, but since QEMU has moved to lowercase CPU model names
> wouldn't it make sense for libvirt to follow suit?

I don't think so. Introducing new aliases (i.e., lower case variants)
for the existing models would IMHO cause more troubles than having a
mixture of upper case and lower case names (once something like power10
is introduced). Users or apps would have to use a crystal ball to check
which CPU model name would be compatible with older libvirt.

Jirka




More information about the libvir-list mailing list