From: Greg Kurz <groug@kaod.org>
To: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
Cao jin <caoj.fnst@cn.fujitsu.com>,
David Gibson <david@gibson.dropbear.id.au>,
Fabiano Rosas <farosas@linux.ibm.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
Richard Henderson <rth@twiddle.net>,
mopsfelder@gmail.com
Subject: Re: [Qemu-devel] [PATCH 1/2] mmap-alloc: unfold qemu_ram_mmap()
Date: Thu, 31 Jan 2019 10:49:42 +0100 [thread overview]
Message-ID: <20190131104942.77053099@bahia.lan> (raw)
In-Reply-To: <20190130233605.22163-2-muriloo@linux.ibm.com>
On Wed, 30 Jan 2019 21:36:04 -0200
Murilo Opsfelder Araujo <muriloo@linux.ibm.com> wrote:
> Unfold parts of qemu_ram_mmap() for the sake of understanding, moving
> declarations to the top, and keeping architecture-specifics in the
> ifdef-else blocks. No changes in the function behaviour.
>
> Give ptr and ptr1 meaningful names:
> ptr -> guardptr : pointer to the PROT_NONE guard region
> ptr1 -> ptr : pointer to the mapped memory returned to caller
>
> Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
> ---
Reviewed-by: Greg Kurz <groug@kaod.org>
> util/mmap-alloc.c | 53 ++++++++++++++++++++++++++++++-----------------
> 1 file changed, 34 insertions(+), 19 deletions(-)
>
> diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
> index fd329eccd8..f71ea038c8 100644
> --- a/util/mmap-alloc.c
> +++ b/util/mmap-alloc.c
> @@ -77,11 +77,19 @@ size_t qemu_mempath_getpagesize(const char *mem_path)
>
> void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared)
> {
> + int flags;
> + int guardfd;
> + size_t offset;
> + size_t total;
> + void *guardptr;
> + void *ptr;
> +
> /*
> * Note: this always allocates at least one extra page of virtual address
> * space, even if size is already aligned.
> */
> - size_t total = size + align;
> + total = size + align;
> +
> #if defined(__powerpc64__) && defined(__linux__)
> /* On ppc64 mappings in the same segment (aka slice) must share the same
> * page size. Since we will be re-allocating part of this segment
> @@ -91,16 +99,22 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared)
> * We do this unless we are using the system page size, in which case
> * anonymous memory is OK.
> */
> - int anonfd = fd == -1 || qemu_fd_getpagesize(fd) == getpagesize() ? -1 : fd;
> - int flags = anonfd == -1 ? MAP_ANONYMOUS : MAP_NORESERVE;
> - void *ptr = mmap(0, total, PROT_NONE, flags | MAP_PRIVATE, anonfd, 0);
> + flags = MAP_PRIVATE;
> + if (fd == -1 || qemu_fd_getpagesize(fd) == getpagesize()) {
> + guardfd = -1;
> + flags |= MAP_ANONYMOUS;
> + } else {
> + guardfd = fd;
> + flags |= MAP_NORESERVE;
> + }
> #else
> - void *ptr = mmap(0, total, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> + guardfd = -1;
> + flags = MAP_PRIVATE | MAP_ANONYMOUS;
> #endif
> - size_t offset;
> - void *ptr1;
>
> - if (ptr == MAP_FAILED) {
> + guardptr = mmap(0, total, PROT_NONE, flags, guardfd, 0);
> +
> + if (guardptr == MAP_FAILED) {
> return MAP_FAILED;
> }
>
> @@ -108,19 +122,20 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared)
> /* Always align to host page size */
> assert(align >= getpagesize());
>
> - offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
> - ptr1 = mmap(ptr + offset, size, PROT_READ | PROT_WRITE,
> - MAP_FIXED |
> - (fd == -1 ? MAP_ANONYMOUS : 0) |
> - (shared ? MAP_SHARED : MAP_PRIVATE),
> - fd, 0);
> - if (ptr1 == MAP_FAILED) {
> - munmap(ptr, total);
> + flags = MAP_FIXED;
> + flags |= fd == -1 ? MAP_ANONYMOUS : 0;
> + flags |= shared ? MAP_SHARED : MAP_PRIVATE;
> + offset = QEMU_ALIGN_UP((uintptr_t)guardptr, align) - (uintptr_t)guardptr;
> +
> + ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE, flags, fd, 0);
> +
> + if (ptr == MAP_FAILED) {
> + munmap(guardptr, total);
> return MAP_FAILED;
> }
>
> if (offset > 0) {
> - munmap(ptr, offset);
> + munmap(guardptr, offset);
> }
>
> /*
> @@ -129,10 +144,10 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared)
> */
> total -= offset;
> if (total > size + getpagesize()) {
> - munmap(ptr1 + size + getpagesize(), total - size - getpagesize());
> + munmap(ptr + size + getpagesize(), total - size - getpagesize());
> }
>
> - return ptr1;
> + return ptr;
> }
>
> void qemu_ram_munmap(void *ptr, size_t size)
next prev parent reply other threads:[~2019-01-31 9:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 23:36 [Qemu-devel] [PATCH 0/2] mmap-alloc: fix hugetlbfs misaligned length in ppc64 Murilo Opsfelder Araujo
2019-01-30 23:36 ` [Qemu-devel] [PATCH 1/2] mmap-alloc: unfold qemu_ram_mmap() Murilo Opsfelder Araujo
2019-01-31 9:49 ` Greg Kurz [this message]
2019-02-01 13:44 ` Balamuruhan S
2019-01-30 23:36 ` [Qemu-devel] [PATCH 2/2] mmap-alloc: fix hugetlbfs misaligned length in ppc64 Murilo Opsfelder Araujo
2019-01-31 9:58 ` Greg Kurz
2019-02-01 13:43 ` Balamuruhan S
2019-02-04 0:08 ` [Qemu-devel] [PATCH 0/2] " David Gibson
2019-02-04 14:27 ` Murilo Opsfelder Araujo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190131104942.77053099@bahia.lan \
--to=groug@kaod.org \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=crosthwaite.peter@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=farosas@linux.ibm.com \
--cc=mopsfelder@gmail.com \
--cc=mst@redhat.com \
--cc=muriloo@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).