On 24.02.20 11:50, David Hildenbrand wrote: > On 19.02.20 23:46, Peter Xu wrote: >> On Wed, Feb 12, 2020 at 02:42:46PM +0100, David Hildenbrand wrote: >>> Factor it out and add a comment. >>> >>> Reviewed-by: Igor Kotrasinski <[email protected]> >>> Acked-by: Murilo Opsfelder Araujo <[email protected]> >>> Reviewed-by: Richard Henderson <[email protected]> >>> Cc: "Michael S. Tsirkin" <[email protected]> >>> Cc: Murilo Opsfelder Araujo <[email protected]> >>> Cc: Greg Kurz <[email protected]> >>> Cc: Eduardo Habkost <[email protected]> >>> Cc: "Dr. David Alan Gilbert" <[email protected]> >>> Cc: Igor Mammedov <[email protected]> >>> Signed-off-by: David Hildenbrand <[email protected]> >>> --- >>> util/mmap-alloc.c | 21 ++++++++++++--------- >>> 1 file changed, 12 insertions(+), 9 deletions(-) >>> >>> diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c >>> index 27dcccd8ec..82f02a2cec 100644 >>> --- a/util/mmap-alloc.c >>> +++ b/util/mmap-alloc.c >>> @@ -82,17 +82,27 @@ size_t qemu_mempath_getpagesize(const char *mem_path) >>> return qemu_real_host_page_size; >>> } >>> >>> +static inline size_t mmap_pagesize(int fd) >>> +{ >>> +#if defined(__powerpc64__) && defined(__linux__) >>> + /* Mappings in the same segment must share the same page size */ >>> + return qemu_fd_getpagesize(fd); >>> +#else >>> + return qemu_real_host_page_size; >>> +#endif >>> +} >> >> Pure question: This will return 4K even for huge pages on x86, is this >> what we want? > > (was asking myself the same question) I *think* it's intended. It's > mainly only used to allocate one additional guard page. The callers of > qemu_ram_mmap() make sure that the size is properly aligned (e.g., to > huge pages). > > Of course, a 4k guard page is sufficient - unless we can't use that > (special case for ppc64 here). > > Thanks! >
We could rename the function to mmap_guard_pagesize(), thoughts? -- Thanks, David / dhildenb
