mmap-alloc: fix hugetlbfs misaligned length in ppc64
commit7265c2b9716369b339d778b9ef64a8161eb8f99b
authorMurilo Opsfelder Araujo <muriloo@linux.ibm.com>
Wed, 30 Jan 2019 23:36:05 +0000 (30 21:36 -0200)
committerMichael S. Tsirkin <mst@redhat.com>
Tue, 5 Feb 2019 15:58:33 +0000 (5 10:58 -0500)
treeb9d56f32f71ac1b9556a2ddc99130bfb9fe81cdf
parent94af9e34821c5c47a3c69fe242e32d0b33c2fff6
mmap-alloc: fix hugetlbfs misaligned length in ppc64

The commit 7197fb4058bcb68986bae2bb2c04d6370f3e7218 ("util/mmap-alloc:
fix hugetlb support on ppc64") fixed Huge TLB mappings on ppc64.

However, we still need to consider the underlying huge page size
during munmap() because it requires that both address and length be a
multiple of the underlying huge page size for Huge TLB mappings.
Quote from "Huge page (Huge TLB) mappings" paragraph under NOTES
section of the munmap(2) manual:

  "For munmap(), addr and length must both be a multiple of the
  underlying huge page size."

On ppc64, the munmap() in qemu_ram_munmap() does not work for Huge TLB
mappings because the mapped segment can be aligned with the underlying
huge page size, not aligned with the native system page size, as
returned by getpagesize().

This has the side effect of not releasing huge pages back to the pool
after a hugetlbfs file-backed memory device is hot-unplugged.

This patch fixes the situation in qemu_ram_mmap() and
qemu_ram_munmap() by considering the underlying page size on ppc64.

After this patch, memory hot-unplug releases huge pages back to the
pool.

Fixes: 7197fb4058bcb68986bae2bb2c04d6370f3e7218
Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
exec.c
include/qemu/mmap-alloc.h
util/mmap-alloc.c
util/oslib-posix.c