RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1595715 - Add ppa15/bpb to the default cpu model for z196 and higher in the 7.6 s390-ccw-virtio machine
Summary: Add ppa15/bpb to the default cpu model for z196 and higher in the 7.6 s390-cc...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-ma
Version: 7.6
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Cornelia Huck
QA Contact: Qunfang Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-27 12:19 UTC by Cornelia Huck
Modified: 2018-10-30 08:05 UTC (History)
8 users (show)

Fixed In Version: qemu-kvm-ma-2.12.0-7.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 08:03:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1612034 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHSA-2018:3062 0 None None None 2018-10-30 08:05:02 UTC

Internal Links: 1612034

Description Cornelia Huck 2018-06-27 12:19:35 UTC
The ppa15/bpb cpu feature bits for spectre mitigation on s390x have been added to the full cpu models in https://bugzilla.redhat.com/show_bug.cgi?id=1535606, but they are not enabled by default. https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg07440.html adds them to the default cpu models for z196 and later for the 3.0 machine. As this makes configuration less error prone, we should add this to the 7.6 machine as well.

Comment 3 Miroslav Rezanina 2018-07-04 08:44:45 UTC
Fix included in qemu-kvm-ma-2.12.0-7.el7

Comment 5 Qunfang Zhang 2018-08-03 09:21:09 UTC
Reproduced on qemu-kvm-ma-2.12.0-6.el7.s390x:

# /usr/libexec/qemu-kvm     -cpu 'z196'      -name 'avocado-vt-vm1'      -sandbox off      -machine s390-ccw-virtio           -device virtio-scsi-ccw,id=virtio_scsi_ccw0     -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/home/qzhang/kar/vt_test_images/ALT-Server-7.6-s390x-virtio-scsi.qcow2     -device scsi-hd,id=image1,drive=drive_image1,bootindex=1     -device virtio-net-ccw,mac=9a:1f:20:21:22:23,id=iduiufBS,netdev=idtlh3FZ      -netdev tap,id=idtlh3FZ,vhost=on,script=/etc/qemu-ifup    -m 2048      -smp 2,maxcpus=2,cores=1,threads=1,sockets=2             -nographic      -rtc base=utc,clock=host,driftfix=slew         -nodefaults     -enable-kvm  -monitor stdio -device sclpconsole,chardev=serial_id_serial0  -chardev socket,id=serial_id_serial0,path=/var/tmp/serial,server,nowait 

(1) -cpu 'z196'
[root@localhost ~]#  grep "^facilities" /proc/cpuinfo 
 grep "^facilities" /proc/cpuinfo 
facilities      : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 47 52 74 75 76 77 138


(2) -cpu 'z114'
# grep "^facilities" /proc/cpuinfo 
grep "^facilities" /proc/cpuinfo 
facilities      : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 47 52 74 75 76 77 138

(3) -cpu 'zEC12'

# grep "^facilities" /proc/cpuinfo 
grep "^facilities" /proc/cpuinfo 
facilities      : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 47 48 49 50 51 52 64 69 71 73 74 75 76 77 78 131 138

(4) -cpu 'zBC12'
# grep "^facilities" /proc/cpuinfo 
grep "^facilities" /proc/cpuinfo 
facilities      : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 47 48 49 50 51 52 64 69 71 73 74 75 76 77 78 131 138


Result:  There are no "81" and "82" facilities bits in guest cpu info.

Comment 6 Qunfang Zhang 2018-08-03 09:22:44 UTC
Re-test on qemu-kvm-ma-2.12.0-9.el7.s390x:

(1) boot guest with -cpu 'z196' ==> Guest failed to boot up and stuck at:

LOADPARM=[        ]
Using virtio-scsi.
Using SCSI scheme.
.....
Uncompressing Linux... Ok, booting the kernel.


"top" on host:

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                   
 13387 root      20   0 2576976 128000  15660 S  99.7  3.3   2:19.79 qemu-kvm                                  
 13476 root      20   0  110508   4256   3572 R   0.3  0.1   0:00.07 top         


(2)Boot guest with -cpu 'z114' ==> Guest failed to boot up and stuck at:

LOADPARM=[        ]
Using virtio-scsi.
Using SCSI scheme.
.....
Uncompressing Linux... Ok, booting the kernel.

"top" on host:

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                   
 14001 root      20   0 2576976 126892  15660 S  98.3  3.2   1:21.05 qemu-kvm                                  
  2238 root      10 -10   14044  14036   3992 S   0.3  0.4   0:00.53 iscsid                                    
     1 root      20   0   91544   9032   5924 S   0.0  0.2   0:03.52 systemd                                   

(3)  -cpu 'zEC12'

#  grep "^facilities" /proc/cpuinfo  | grep "81 82"
 grep "^facilities" /proc/cpuinfo  | grep "81 82"
facilities      : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 47 48 49 50 51 52 64 69 71 73 74 75 76 77 78 81 82 131 138



(4) -cpu 'zBC12'
# grep "^facilities" /proc/cpuinfo | grep "81 82"
grep "^facilities" /proc/cpuinfo 
facilities      : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 47 48 49 50 51 52 64 69 71 73 74 75 76 77 78 81 82 131 138

Comment 7 Qunfang Zhang 2018-08-03 09:25:17 UTC
Hi, Cornelia

Could you give a help to review comment 6? I think for "zEC12" and "zBC12" cpu models, the bug is fixed since "81 82" facilities bits are set.

However when I boot guest with "-cpu z196" or "-cpu z114", guest failed to boot up. This issue didn't exist in qemu-kvm-ma-2.12.0-6.el7.s390x.

Is this a new issue?

My host cpuinfo:

# cat /proc/cpuinfo 
vendor_id       : IBM/S390
# processors    : 2
bogomips per cpu: 2913.00
max thread id   : 0
features	: esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te sie 
facilities      : 0 1 2 3 4 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 46 47 48 49 50 51 52 57 64 65 66 67 68 69 70 71 72 73 75 76 77 78 81 82 131 132
cache0          : level=1 type=Data scope=Private size=96K line_size=256 associativity=6
cache1          : level=1 type=Instruction scope=Private size=64K line_size=256 associativity=4
cache2          : level=2 type=Data scope=Private size=1024K line_size=256 associativity=8
cache3          : level=2 type=Instruction scope=Private size=1024K line_size=256 associativity=8
cache4          : level=3 type=Unified scope=Shared size=49152K line_size=256 associativity=12
cache5          : level=4 type=Unified scope=Shared size=393216K line_size=256 associativity=24
processor 0: version = 00,  identification = 3EC047,  machine = 2827
processor 1: version = 00,  identification = 3EC047,  machine = 2827

cpu number      : 0
cpu MHz dynamic : 5504
cpu MHz static  : 5504

cpu number      : 1
cpu MHz dynamic : 5504
cpu MHz static  : 5504


Thanks,
Qunfang

Comment 8 Qunfang Zhang 2018-08-03 09:31:09 UTC
The issue for failing to boot up guest with "-cpu z196" or "-cpu z114", was introduced in qemu-kvm-ma-2.12.0-7.el7.s390x.

Comment 9 David Hildenbrand 2018-08-03 09:32:10 UTC
Is the kernel compatible with z196/z114 at all? I thought it would be compiled for z12+. Are you using the exact same guest kernel in both setups?

Comment 10 Qunfang Zhang 2018-08-03 09:50:29 UTC
(In reply to David Hildenbrand from comment #9)
> Is the kernel compatible with z196/z114 at all? I thought it would be
> compiled for z12+. Are you using the exact same guest kernel in both setups?

Yeah, for both test (comment 5 and comment 6), I used  Kernel 4.14.0-92.el7a.s390x as the guest kernel, it's not the latest 7.6-alt version though.

Comment 11 Cornelia Huck 2018-08-03 10:45:45 UTC
This looks like a preexisting bug with the z196/z114 cpu models, the bpb/ppa15 bits, and (at least) the -alt kernel. As stated in https://bugzilla.redhat.com/show_bug.cgi?id=1612034, this works if the features are turned off manually, and it also starts to fail if they are added manually on a QEMU without this patch.

I'm suspecting this is a bug in the spectre mitigation code in the kernel.

Comment 12 Qunfang Zhang 2018-08-06 01:44:35 UTC
Based on comment 11, I set bug status to VERIFIED and use bug 1612034 to track the guest kernel issue.  Thanks.

Comment 14 errata-xmlrpc 2018-10-30 08:03:37 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://access.redhat.com/errata/RHSA-2018:3062


Note You need to log in before you can comment on or make changes to this bug.