All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Alexander Graf <agraf@suse.de>, Stefan Weil <sw@weilnetz.de>
Subject: Re: [Qemu-devel] [PATCH v2 2/4] util/oslib-win32: indicate alignment for qemu_anon_ram_alloc()
Date: Fri, 29 Jun 2018 16:49:03 +0200	[thread overview]
Message-ID: <20180629164903.1630ea28@redhat.com> (raw)
In-Reply-To: <20180628121417.1980-3-david@redhat.com>

On Thu, 28 Jun 2018 14:14:15 +0200
David Hildenbrand <david@redhat.com> wrote:

> Let's set the alignment just like for the posix variant. This will
> implicitly set the alignment of the underlying memory region and
> therefore make memory_region_get_alignment(mr) return something > 0 for
> all memory backends applicable to PCDIMM/NVDIMM.
> 
> This will allow us to drop special handling in pc.c for
> memory_region_get_alignment(mr) == 0, as we can then assume that it is
> always set (and AFAICS >= getpagesize()).
> 
> For pc in pc_memory_plug(), under Windows TARGET_PAGE_SIZE == getpagesize(),
> therefore alignment of DIMMs will not change, and therefore also not the
> guest physical memory layout.
why not use QEMU_VMALLOC_ALIGN for consistency (on win => getpagesize())
instead of TARGET_PAGE_SIZE like linux allocator does?

Also looking at FIXME comment it notes that VirtualAlloc might have 64K
alignment (though I haven't found it in VirtualAlloc manual).
If that's true then we might need set *align to it to avoid auto-picked
address overlap with previous allocation (not really sure about it).


> For spapr in spapr_memory_plug(), an alignment of 0 would have been used
note that align == 0 would lead to crash where QEMU_ALIGN_UP() is used,
so we don't care to keep it compatible (the same like in commit 92a37a04d)

> until now. Now getpagesize() is used. But as the size of DIMMs has to be
> multiple of 256MB on spapr, automatic address asignment will not change
> the layout (no memory holes will be created as the alignment change will
> not apply if DIMMs start/end on 256MB boundaries).
> 
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  util/oslib-win32.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/util/oslib-win32.c b/util/oslib-win32.c
> index bb5ad28bd3..6e87721419 100644
> --- a/util/oslib-win32.c
> +++ b/util/oslib-win32.c
> @@ -76,6 +76,10 @@ void *qemu_anon_ram_alloc(size_t size, uint64_t *align, bool shared)
>         memory is page aligned. */
>      ptr = VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE);
>      trace_qemu_anon_ram_alloc(size, ptr);
> +
> +    if (ptr && align) {
> +        *align = getpagesize();
> +    }
>      return ptr;
>  }
>  

  parent reply	other threads:[~2018-06-29 14:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 12:14 [Qemu-devel] [PATCH v2 0/4] pc-dimm: pre_plug "slot" and "addr" assignment David Hildenbrand
2018-06-28 12:14 ` [Qemu-devel] [PATCH v2 1/4] pc-dimm: assign and verify the "slot" property during pre_plug David Hildenbrand
2018-06-28 12:14 ` [Qemu-devel] [PATCH v2 2/4] util/oslib-win32: indicate alignment for qemu_anon_ram_alloc() David Hildenbrand
2018-06-29  1:16   ` David Gibson
2018-06-29 14:49   ` Igor Mammedov [this message]
2018-06-29 15:39     ` David Hildenbrand
2018-06-29 15:56       ` Igor Mammedov
2018-06-29 16:14         ` David Hildenbrand
2018-06-28 12:14 ` [Qemu-devel] [PATCH v2 3/4] pc: drop memory region alignment check for 0 David Hildenbrand
2018-06-29  1:16   ` David Gibson
2018-06-29 14:51   ` Igor Mammedov
2018-06-28 12:14 ` [Qemu-devel] [PATCH v2 4/4] pc-dimm: assign and verify the "addr" property during pre_plug David Hildenbrand
2018-06-29  1:19   ` David Gibson
2018-06-29  7:14     ` David Hildenbrand
2018-06-29 14:59       ` Igor Mammedov
2018-06-29 15:08   ` Igor Mammedov
2018-06-29 15:46     ` David Hildenbrand

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=20180629164903.1630ea28@redhat.com \
    --to=imammedo@redhat.com \
    --cc=agraf@suse.de \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sw@weilnetz.de \
    --cc=xiaoguangrong.eric@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.