[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias
From: |
Thomas Huth |
Subject: |
Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling |
Date: |
Tue, 9 Aug 2016 18:22:05 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 |
On 09.08.2016 17:39, Bharata B Rao wrote:
> On Tue, Aug 09, 2016 at 11:17:04AM +0200, Thomas Huth wrote:
>> There is a regression with the "-cpu" parameter which has been
>> introduced by the spapr CPU hotplug code: We used to allow to specify
>> a "CPU family" name with the "-cpu" parameter when running on KVM so
>> that the user does not need to know the gory details of the exact
>> CPU version of the host CPU. For example, it was possible to
>> use "-cpu POWER8" on a POWER8E host CPU. This behavior does not
>> work anymore with the new hot-pluggable spapr-cpu-core types.
>> Since libvirt already heavily depends on the old behavior, this
>> is quite a severe regression in the QEMU parameter interface, thus
>> I think these patches should still go into 2.7 if possible, to avoid
>> that we break the "upper layers" with the final 2.7 release.
>
> 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. 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.
> 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.
Thomas
- [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling, Thomas Huth, 2016/08/09
- [Qemu-devel] [PATCH 2/5] hw/ppc/spapr: Look up CPU alias names instead of hard-coding the aliases, Thomas Huth, 2016/08/09
- [Qemu-devel] [PATCH 1/5] ppc: Introduce a function to look up CPU alias strings, Thomas Huth, 2016/08/09
- [Qemu-devel] [PATCH 3/5] hw/ppc/spapr: Do not leak the memory of the type string, Thomas Huth, 2016/08/09
- [Qemu-devel] [PATCH 5/5] ppc/kvm: Register also a generic spapr CPU core family type, Thomas Huth, 2016/08/09
- [Qemu-devel] [PATCH 4/5] ppc/kvm: Do not mess up the generic CPU family registration, Thomas Huth, 2016/08/09
- Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling, Andrea Bolognani, 2016/08/09
- Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling, Bharata B Rao, 2016/08/09
- Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling,
Thomas Huth <=
- Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling, Thomas Huth, 2016/08/09