Bug 1703765

Summary:	[RHEL7] QEMU dies unhappy death if nr of huge page is zero.
Product:	Red Hat Enterprise Linux 7	Reporter:	Min Deng <mdeng>
Component:	qemu-kvm-rhev	Assignee:	David Gibson <dgibson>
Status:	CLOSED WONTFIX	QA Contact:	Min Deng <mdeng>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.7	CC:	mdeng, michen, ngu, qzhang, virt-maint, xuma, yihyu, zhenyzha
Target Milestone:	rc
Target Release:	---
Hardware:	ppc64le
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-23 01:35:55 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:	1686261
Bug Blocks:

Description Min Deng 2019-04-28 07:59:37 UTC

Description of problem:
[RHEL7]QEMU dies unhappy death if nr of huge page is zero. 

Version-Release number of selected component (if applicable):
kernel-3.10.0-1037.el7.ppc64le
qemu-kvm-rhev-2.12.0-26.el7.ppc64le

How reproducible:
3/3

Steps to Reproduce:
1.Configure huge page on P8 host
  mkdir /dev/hugepages
  mount -t hugetlbfs -o pagesize=16M none /dev/hugepages
  echo 15000 > /proc/sys/vm/nr_hugepages
  echo 0 > /sys/devices/system/node/node0/hugepages/hugepages-16384kB/nr_hugepages
  [root@ibm-p8-kvm-02-qe runs]# cat /sys/devices/system/node/node*/meminfo | fgrep Huge
  Node 0 AnonHugePages:         0 kB
  Node 0 HugePages_Total:     0
  Node 0 HugePages_Free:      0
  Node 0 HugePages_Surp:      0

2.Bind guest's memory on numa node 0 
numactl --membind=0 numactl --membind=0 /usr/libexec/qemu-kvm -name avocado-vt-vm1 -machine pseries,max-cpu-compat=power8 -nodefaults -device VGA,bus=pci.0,addr=0x2 -chardev socket,id=serial_id_serial0,path=/tmp/5,server,nowait -device spapr-vty,reg=0x30000000,chardev=serial_id_serial0 -device qemu-xhci,id=usb1,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4 -device scsi-hd,id=image1,drive=drive_scsi11,bus=virtio_scsi_pci0.0,channel=0,scsi-id=0,lun=0,bootindex=0 -blockdev driver=file,cache.direct=on,cache.no-flush=off,filename=rhel76-ppc64-virtio-scsi.qcow2,node-name=drive_scsi1 -blockdev driver=qcow2,node-name=drive_scsi11,file=drive_scsi1 -m 1G,slots=256,maxmem=2T -mem-path /dev/hugepages -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 -monitor stdio

Actual results:
QEMU 2.12.0 monitor - type 'help' for more information
(qemu) Bus error
and QEMU quits finally

Expected results:
It's an extreme situation,whatever it is not a good result for QEMU dies such unhappy death.

Additional info
Probably,the below result should be preferred.

1.Inadequate huge pages were set unfortunately before booting up a guest
 
[root@ibm-p8-rhevm-07 mdeng]# cat /proc/meminfo|grep Huge
AnonHugePages:         0 kB
HugePages_Total:      10
HugePages_Free:       10
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:      16384 kB

2.boot up a guest 
CLI,
...-m 5G -mem-path /mnt/kvm_hugepage -numa node,mem=5G,cpus=0,nodeid=0 -numa node...

QEMU 2.12.0 monitor - type 'help' for more information
(qemu) qemu-kvm: unable to map backing store for guest RAM: Cannot allocate memory
qemu-kvm: falling back to regular RAM allocation.

Comment 2 David Gibson 2019-05-06 04:15:57 UTC

Min,

Does this problem also occur with RHEL8.0 or RHEL8.1?

Comment 3 Min Deng 2019-05-06 05:07:15 UTC

Hi David,
   The problem also occurred on rhel8.0.
Thanks.
Min

Comment 4 Min Deng 2019-05-06 05:08:08 UTC

For your reference,
Bug 1686261 - [RHEL8]QEMU dies unhappy death if nr of huge page is zero.

Comment 5 David Gibson 2019-05-23 01:35:55 UTC

This is actually pretty difficult to fix in the code, I'm looking at options but it might not be worth the trouble, since this is purely to improve an error message in a case which definitely can't work.

Note that you can workaround this by adding the "-mem-prealloc" option.  With that option qemu will check for available memory earlier and fail with a nicer message.

This definitely isn't severe enough to fix in RHEL7, especially since the code change would need to be quite significant.