Bug 2117149

Summary: Can't run when memory backing with hugepages and backend type memfd
Product: Red Hat Enterprise Linux 8 Reporter: Thomas Huth <thuth>
Component: qemu-kvmAssignee: Cédric Le Goater <clegoate>
qemu-kvm sub component: General QA Contact: smitterl
Status: CLOSED ERRATA Docs Contact: Parth Shah <pashah>
Severity: low    
Priority: low CC: dhildenb, jherrman, pashah, smitterl, thuth, virt-maint, virt-qe-z
Version: 8.7Keywords: Automation, Triaged
Target Milestone: rc   
Target Release: 8.8   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: qemu-kvm-6.2.0-21.module+el8.8.0+16769+2aec4a1c Doc Type: Bug Fix
Doc Text:
.Virtual machines using `memfd` run as expected Previously, virtual machines (VMs) running on the 64-bit IBM Z processor architecture that used `memfd` to back memory with hugepages failed to run. With this update, the problem has been fixed and VMs using `memfd` can now be defined on the 64-bit IBM Z processor architecture. As a result, you can now run VMs which use `memfd` to back the memory with hugepages.
 Story Points: ---
Clone Of: 2116496 Environment:
Last Closed: 2023-05-16 08:16:30 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:

Description Thomas Huth 2022-08-10 06:52:02 UTC 
+++ This bug was initially created as a clone of Bug #2116496 +++

Description of problem:
A machine with memory backing via hugepages using the memfd backend doesn't run.

Version-Release number of selected component (if applicable):
qemu-kvm-7.0.0-9.el9.s390x

How reproducible:
100%


Steps to Reproduce:
0. Make sure hugepages are enabled for KVM (modprobe kvm hpage=1)
1. Start a machine with -object {"qom-type":"memory-backend-memfd","id":"s390.ram","hugetlb":true,"hugetlbsize":1048576,"x-use-canonical-path-for-ramblock-id":false,"prealloc":true,"size":1073741824}
OR equivalently, in libvirt define
<memoryBacking>
  <hugepages/>
  <source type='memfd'/>
</memoryBacking>

Actual results:
The machine is immediately paused; there's an error: kvm run failed Bad address
PSW=mask 0000000180000000 addr 000000003fe00510
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
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:
The machine runs.

Additional info:
a) The machine runs successfully on x86_64 (used qemu-kvm-6.2.0-11.el9_0.3.x86_64).
b) It reproduces with qemu-kvm-6.2.0-11.el9_0.2.s390x.
c) Not considering critical at this point as we can still use the memory-backend-file instead of memory-backend-memfd successfully.
d) Using memory-backend-memfd without hugepages works, too.


--- Additional comment from Thomas Huth on 2022-08-09 12:14:02 CEST ---

For reproducing without libvirt, these QEMU command lines can be used, too:

- memory-backend-file (working):

  qemu-system-s390x --accel kvm -m 4G -nographic -hda rhel8.qcow2 \
   -M s390-ccw-virtio,memory-backend=s390.ram \
   -object '{"qom-type":"memory-backend-file","id":"s390.ram","mem-path":"/dev/hugepages/","x-use-canonical-path-for-ramblock-id":false,"prealloc":true,"size":4294967296}'

- memory-backend-memfd (non-working):

  qemu-system-s390x --accel kvm -m 4G -nographic -hda rhel8.qcow2 \
   -M s390-ccw-virtio,memory-backend=s390.ram \
  -object '{"qom-type":"memory-backend-memfd","id":"s390.ram","hugetlb":true,"hugetlbsize":1048576,"x-use-canonical-path-for-ramblock-id":false,"prealloc":true,"size":4294967296}'

--- Additional comment from Thomas Huth on 2022-08-09 12:21:59 CEST ---

Seems like s390_set_max_pagesize() in the QEMU sources does not activate the huge pages since qemu_maxrampagesize() only returns 4096 on s390x ... and looking a little bit closer, this happens because host_memory_backend_pagesize() is only able to deal with objects of type memory-backend-file...

--- Additional comment from Thomas Huth on 2022-08-10 08:47:41 CEST ---

I suggested a patch upstream here: https://lore.kernel.org/qemu-devel/20220810063204.3589543-1-thuth@redhat.com/
Comment 1 Thomas Huth 2022-09-22 08:50:34 UTC 
The fix is available in upstream here:

https://gitlab.com/qemu-project/qemu/-/commit/8be934b70e923104da883b990dee18f02552d40e
Comment 11 smitterl 2022-10-19 11:10:23 UTC 
Verified with qemu-kvm-6.2.0-22.module+el8.8.0+16816+1d3555ec.s390x
Comment 16 errata-xmlrpc 2023-05-16 08:16:30 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 (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), 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-2023:2757