1672919 – Trying to start a guest with hugetlbfs backing does not bail out so providing saying that hugetlbfs is not supported before actually trying to start the guest. [rhel-7.6.z]

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 1672919 - Trying to start a guest with hugetlbfs backing does not bail out so providing saying that hugetlbfs is not supported before actually trying to start the guest. [rhel-7.6.z]

Summary: Trying to start a guest with hugetlbfs backing does not bail out so providing...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	qemu-kvm-ma
Sub Component:
Version:	7.6-Alt
Hardware:	s390x
OS:	Linux
Priority:	high
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Virtualization Maintenance
QA Contact:	Min Deng
Docs Contact:
URL:
Whiteboard:
Depends On:	1650580
Blocks:
TreeView+	depends on / blocked

Reported:	2019-02-06 08:28 UTC by RAD team bot copy to z-stream
Modified:	2019-03-13 18:46 UTC (History)
CC List:	5 users (show)
Fixed In Version:	qemu-kvm-ma-2.12.0-18.el7_6.1
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:	1650580
Environment:
Last Closed:	2019-03-13 18:46:07 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2019:0510	0	None	None	None	2019-03-13 18:46:10 UTC

Description RAD team bot copy to z-stream 2019-02-06 08:28:59 UTC

This bug has been copied from bug #1650580 and has been proposed to be backported to 7.6 z-stream (EUS).

Comment 2 Miroslav Rezanina 2019-02-06 11:11:11 UTC

Fix included in qemu-kvm-ma-2.12.0-18.el7_6.1

Comment 4 Min Deng 2019-02-12 08:37:16 UTC

Reproduced the bug on the following builds
kernel-4.14.0-115.el7a.s390x
qemu-kvm-ma-2.12.0-18.el7.s390x
Steps,
*Enabled Huge page on host beforehand
1.mount -t hugetlbfs none /mnt/kvm_hugepage
2.echo 1024 > /proc/sys/vm/nr_hugepages 
3.boot up a guest with huge page 
/usr/libexec/qemu-kvm -name avocado-vt-vm1 -sandbox off -machine s390-ccw-virtio -nodefaults -vga none -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/1,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -chardev socket,id=qmp_id_catch_monitor,path=/tmp/2,server,nowait -mon chardev=qmp_id_catch_monitor,mode=control -chardev socket,id=serial_id_serial0,path=/tmp/3,server,nowait -device sclpconsole,chardev=serial_id_serial0 -device virtio-scsi-ccw,id=virtio_scsi_ccw0 -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=rhel76-s390x-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image1 -m 1024 -mem-path /mnt/kvm_hugepage -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 -cpu host -nographic -rtc base=utc,clock=host,driftfix=slew -boot strict=on -no-shutdown -enable-kvm -monitor stdio

Actual results,
(qemu) qemu-kvm: warning: CMM will not be enabled because it is not compatible with hugetlbfs.
error: kvm run failed Bad address
PSW=mask 0000000180000000 addr 000000003fe006e0 cc 00
R00=0000000000000000 R01=0000000000000000 R02=0000000000000000 R03=0000000000000000
R04=0000000000000000 R05=0000000000000000 R06=0000000000000000 R07=0000000000000000
R08=0000000000000000 R09=0000000000000000 R10=0000000000000000 R11=0000000000000000
R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
F00=0000000000000000 F01=0000000000000000 F02=0000000000000000 F03=0000000000000000
F04=0000000000000000 F05=0000000000000000 F06=0000000000000000 F07=0000000000000000
F08=0000000000000000 F09=0000000000000000 F10=0000000000000000 F11=0000000000000000
F12=0000000000000000 F13=0000000000000000 F14=0000000000000000 F15=0000000000000000
V00=00000000000000000000000000000000 V01=00000000000000000000000000000000
V02=00000000000000000000000000000000 V03=00000000000000000000000000000000
V04=00000000000000000000000000000000 V05=00000000000000000000000000000000
V06=00000000000000000000000000000000 V07=00000000000000000000000000000000
V08=00000000000000000000000000000000 V09=00000000000000000000000000000000
V10=00000000000000000000000000000000 V11=00000000000000000000000000000000
V12=00000000000000000000000000000000 V13=00000000000000000000000000000000
V14=00000000000000000000000000000000 V15=00000000000000000000000000000000
V16=00000000000000000000000000000000 V17=00000000000000000000000000000000
V18=00000000000000000000000000000000 V19=00000000000000000000000000000000
V20=00000000000000000000000000000000 V21=00000000000000000000000000000000
V22=00000000000000000000000000000000 V23=00000000000000000000000000000000
V24=00000000000000000000000000000000 V25=00000000000000000000000000000000
V26=00000000000000000000000000000000 V27=00000000000000000000000000000000
V28=00000000000000000000000000000000 V29=00000000000000000000000000000000
V30=00000000000000000000000000000000 V31=00000000000000000000000000000000
C00=00000000000000e0 C01=0000000000000000 C02=0000000000000000 C03=0000000000000000
C04=0000000000000000 C05=0000000000000000 C06=0000000000000000 C07=0000000000000000
C08=0000000000000000 C09=0000000000000000 C10=0000000000000000 C11=0000000000000000
C12=0000000000000000 C13=0000000000000000 C14=00000000c2000000 C15=0000000000000000

Expected results,
QEMU will properly bail out, saying that hugetlbfs is not supported before actually trying to start the guest.

Comment 5 Min Deng 2019-02-12 08:42:34 UTC

Verified the bug on the following builds
kernel-4.14.0-115.5.1.el7a.s390x
qemu-kvm-ma-2.12.0-18.el7_6.1.s390x

Steps,
*Enabled Huge page on host beforehand
1.mount -t hugetlbfs none /mnt/kvm_hugepage
2.echo 1024 > /proc/sys/vm/nr_hugepages 
3.boot up a guest with huge page 
/usr/libexec/qemu-kvm -name avocado-vt-vm1 -sandbox off -machine s390-ccw-virtio -nodefaults -vga none -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/1,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -chardev socket,id=qmp_id_catch_monitor,path=/tmp/2,server,nowait -mon chardev=qmp_id_catch_monitor,mode=control -chardev socket,id=serial_id_serial0,path=/tmp/3,server,nowait -device sclpconsole,chardev=serial_id_serial0 -device virtio-scsi-ccw,id=virtio_scsi_ccw0 -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=rhel76-s390x-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image1 -m 1024 -mem-path /mnt/kvm_hugepage -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 -cpu host -nographic -rtc base=utc,clock=host,driftfix=slew -boot strict=on -no-shutdown -enable-kvm -monitor stdio

Actual results,
QEMU will properly bail out, saying that hugetlbfs is not supported before actually trying to start the guest.

/usr/libexec/qemu-kvm -name avocado-vt-vm1 -sandbox off -machine s390-ccw-virtio -nodefaults -vga none -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/1,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -chardev socket,id=qmp_id_catch_monitor,path=/tmp/2,server,nowait -mon chardev=qmp_id_catch_monitor,mode=control -chardev socket,id=serial_id_serial0,path=/tmp/3,server,nowait -device sclpconsole,chardev=serial_id_serial0 -device virtio-scsi-ccw,id=virtio_scsi_ccw0 -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=rhel76-s390x-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image1 -m 1024 -mem-path /mnt/kvm_hugepage -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 -cpu host -nographic -rtc base=utc,clock=host,driftfix=slew -boot strict=on -no-shutdown -enable-kvm -monitor stdio
qemu-kvm: This QEMU does not support huge page mappings
qemu-kvm: failed to initialize KVM: Invalid argument


Expected results,
QEMU will properly bail out, saying that hugetlbfs is not supported before actually trying to start the guest.


Base on above results, the problem has been fixed already,thanks!

Comment 7 errata-xmlrpc 2019-03-13 18:46:07 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/RHBA-2019:0510

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