Bug 1291209

Summary: The cpu model that could be boot in command line does not match with host /proc/cpuinfo
Product: Red Hat Enterprise Linux 7 Reporter: Qunfang Zhang <qzhang>
Component: qemu-kvm-rhevAssignee: David Gibson <dgibson>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: abologna, hannsj_uhl, knoel, mdeng, michen, mrezanin, thuth, virt-maint, xuhan, xuma, zhengtli
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: qemu-2.6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-07 21:45:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1288337, 1359843    

Description Qunfang Zhang 2015-12-14 10:07:53 UTC
Description of problem:
Check that host cpu is POWER8E (with "cat /proc/cpuinfo"), but can not boot guest with "-cpu POWER8E". "-cpu POWER8" is okay instead. I don't try the upstream code, but Thomas told me latest upstream QEMU works as expected.

Version-Release number of selected component (if applicable):
kernel-3.10.0-327.4.1.el7.ppc64le
qemu-kvm-rhev-2.3.0-31.el7_2.3.ppc64le


How reproducible:
Always

Steps to Reproduce:
1. On host: 
#cat /proc/cpuinfo
......
processor	: 152
cpu		: POWER8E (raw), altivec supported
clock		: 3690.000000MHz
revision	: 2.1 (pvr 004b 0201)


2. Start a qemu command line:

# /usr/libexec/qemu-kvm -cpu POWER8E
kvm_init_vcpu failed: Invalid argument

# /usr/libexec/qemu-kvm -cpu POWER8
VNC server running on `::1:5900'

3.

Actual results:


Expected results:
POWER8E is bootable in this case.

Additional info:

Comment 2 Thomas Huth 2016-01-12 12:32:58 UTC
I just tried this again with latest upstream version of QEMU - and it also does not work there (I likely forgot to use -enable-kvm in my earlier tests, that's why I thought it would be working there).

After analyzing the code for a while, I think the problem is in kvm_ppc_register_host_cpu_type(): This functions registers two CPU class types with the PVR of the host, one named "host-powerpc64-cpu" and one named "POWER8-powerpc64-cpu" ... so the latter overrides the default "POWER8" CPU class when KVM is enabled. But this of course does not override the "POWER8E" class, thus using "-cpu POWER8E" does not work yet when KVM is enabled.

I guess we should either have some additional logic in there to override "POWER8E", too, ... I'll have a closer look whether this can be done in a feasible way...

Comment 3 Andrea Bolognani 2016-01-12 13:16:39 UTC
I'm unable to find a pointer at the moment, but when this was
discussed in the context of fixing libvirt's handling of POWER CPU
models, the recommendation from QEMU developers was to just always
use '-cpu POWER8' if the host CPU belongs to the POWER8 family.

libvirt has implemented that suggestion last August (see Bug 1250977)
and will now only advertise and accept family names as CPU
specification for POWER hosts:

  $ sudo virsh cpu-models ppc64 | grep POWER8
  POWER8

  $ sudo virsh capabilities | grep POWER
        <model>POWER8</model>

  $ grep POWER /proc/cpuinfo | head -1
  cpu       : POWER8E (raw), altivec supported

So from libvirt's point of view any variant of POWER8, including
POWER8E, will always be exposed to the user as POWER8.

I guess adding logic to make '-cpu POWER8E' behave as '-cpu POWER8'
on POWER8E hosts won't hurt, I just wanted to make you aware of
libvirt's point of view here :)

Comment 4 Thomas Huth 2016-01-12 16:46:08 UTC
Looks like this can be fixed by applying this patch here, since it introduces the CPUs with the proper PVR values into QEMU:

https://lists.gnu.org/archive/html/qemu-ppc/2015-11/msg00092.html

However, that has not been merged into upstream yet. So I'm assigning this bug ticket back to David, since he's involved in the discussion of that patch series already.

Comment 5 David Gibson 2016-01-15 02:06:51 UTC
Re: comment 4

I've now taken that patch into my upstream ppc-for-2.6 tree, so it will go with my next patch of upstream patches.

Comment 6 Thomas Huth 2016-02-04 10:40:26 UTC
Patch is now in upstream, we should get it automatically when rebasing to QEMU 2.6:

http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9d6ba75df26d699a6e23d4817983bd02

Comment 7 Mike McCune 2016-03-28 22:28:36 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 9 Qunfang Zhang 2016-06-03 03:10:35 UTC
Verified the bug on qemu-kvm-rhev-2.6.0-4.el7.ppc64le. 

Currently qemu-kvm-rhev only provides the following cpu models:

[root@ibm-p8-kvm-02-qe qemu]# /usr/libexec/qemu-kvm -cpu ?
PowerPC POWER7_v2.3      PVR 003f0203
PowerPC POWER7           (alias for POWER7_v2.3)
PowerPC POWER7+_v2.1     PVR 004a0201
PowerPC POWER7+          (alias for POWER7+_v2.1)
PowerPC POWER8E_v2.1     PVR 004b0201
PowerPC POWER8E          (alias for POWER8E_v2.1)
PowerPC POWER8NVL_v1.0   PVR 004c0100
PowerPC POWER8NVL        (alias for POWER8NVL_v1.0)
PowerPC POWER8_v2.0      PVR 004d0200
PowerPC POWER8           (alias for POWER8_v2.0)

PowerPC host            

My host cpu info:

processor	: 152
cpu		: POWER8E (raw), altivec supported
clock		: 3690.000000MHz
revision	: 2.1 (pvr 004b 0201)

Now I can only boot guest with the following cpu models on this host:
POWER8E_v2.1
POWER8E
POWER8
host

For all the other cpu models, qemu-kvm-rhev will prompts: 

# /usr/libexec/qemu-kvm -cpu POWER8_v2.0
qemu-kvm: Register sync failed... If you're using kvm-hv.ko, only "-cpu host" is possible
kvm_init_vcpu failed: Invalid argument

Since guest can boot with POWER8E(same as host), POWER8 and host cpu models, so I think this bug could be verified, please correct me if something is wrong.  Thanks.

Comment 11 errata-xmlrpc 2016-11-07 21:45:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html