On 16.05.25 14:39, David Hildenbrand wrote:
If s390_wiggle_split_folio() returns 0 because splitting a large folio succeeded, we will return 0 from make_hva_secure() even though a retry is required. Return -EAGAIN in that case.
Otherwise, we'll return 0 from gmap_make_secure(), and consequently from unpack_one(). In kvm_s390_pv_unpack(), we assume that unpacking succeeded and skip unpacking this page. Later on, we run into issues and fail booting the VM.
So far, this issue was only observed with follow-up patches where we split large pagecache XFS folios. Maybe it can also be triggered with shmem?
Yes! I can reproduce it when allocating pages outside of the qemu process.
$ echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled $ rm /dev/shm/vm-ram $ fallocate -l 4G /dev/shm/vm-ram $ /usr/libexec/qemu-kvm ... -object memory-backend-file,id=mem0,size=4g,share=on,mem-path=/dev/shm/vm-ram -M memory-backend=mem0
LOADPARM=[ ]
Using virtio-blk. Using SCSI scheme. ......................................................................................................................... qemu-kvm: KVM PV command 4 (KVM_PV_VERIFY) failed: header rc 102 rrc 1a IOCTL rc: -22 Protected boot has failed: 0xa02 Guest crashed on cpu 0: disabled-wait PSW: 0x0002000080000000 0x0000000000004608