Red Hat Bugzilla – Bug 1595715
Add ppa15/bpb to the default cpu model for z196 and higher in the 7.6 s390-ccw-virtio machine
Last modified: 2018-10-30 04:05:02 EDT
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.
Fix included in qemu-kvm-ma-2.12.0-7.el7
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.
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
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
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.
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?
(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.
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.
Based on comment 11, I set bug status to VERIFIED and use bug 1612034 to track the guest kernel issue. Thanks.
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