Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling

[Andrea Bolognani <abologna@redhat.com>]

On Tue, 2016-08-09 at 18:22 +0200, Thomas Huth wrote:
> > I believed that "-cpu POWER8" on POWER8E host was broken in a way as
> > the guest CPUs were getting reported as POWER8E instead of POWER8
> > 
> > (/proc/cpuinfo of guest)
> > cpu		: POWER8E (raw), altivec supported
> > 
> > I thought, the correct configuration should have been
> > 
> > cpu             : POWER8 (architected), altivec supported
> > 
> > which is what you get when you use POWER8 in compat mode on
> > POWER8E host like below:
> > 
> > -cpu host -global driver=host-powerpc64-cpu,property=compat,value=power8
> 
> As far as I've understood the (old) QEMU source code and the discussions
> in the past, the "-cpu POWER8" was rather meant as some kind of alias
> for any CPU in the POWER8 family, i.e. also for POWER8E CPUs.

Indeed. See

  https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg01993.html

and in particular

  https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg02007.html

for the rationale.

> It's just
> a little bit ugly that "-cpu ?" always lists this as an alias for
> POWER8_v2.0 - it would be better if we'd somehow update it when we set
> the POWER8 alias on KVM.

AFAIU that won't be possible, because QEMU doesn't know (and
doesn't want to know) about every single existing POWER CPU
ever built. But agreed, it's kinda ugly.

> > However as you note libvirt is dependent on supporting POWER8 and
> > there have been discussions and conclusions on this earlier, I guess
> > it is better now to have your patchset to restore the expectations of
> > libvirt.
> 
> Yes, I think we should keep the old behavior now to avoid to break
> things ... we maybe might want to reconsider the behavior for future
> CPUs (POWER9?) though.

If such a change is ever implemented, hopefully it will be
possible to keep the old behavior around not only for
POWER[6-8] but also for POWER9, while providing the new
behavior as an alternative.

In any case, when this or similar incompatible changes are
discussed, please try to keep libvirt folks in the loop. In
praticular, feel absolutely free to CC: me any time you feel
the discussion might be relevant :)

-- 
Andrea Bolognani / Red Hat / Virtualization