Bug 2117149

+++ 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/