diff options
author | Murilo Opsfelder Araujo <muriloo@linux.ibm.com> | 2019-01-30 21:36:05 -0200 |
---|---|---|
committer | Michael S. Tsirkin <mst@redhat.com> | 2019-02-05 10:58:33 -0500 |
commit | 7265c2b9716369b339d778b9ef64a8161eb8f99b (patch) | |
tree | b9d56f32f71ac1b9556a2ddc99130bfb9fe81cdf /hw/sh4/r2d.c | |
parent | 94af9e34821c5c47a3c69fe242e32d0b33c2fff6 (diff) |
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>
Diffstat (limited to 'hw/sh4/r2d.c')
0 files changed, 0 insertions, 0 deletions