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 17:56:41 +0200	[thread overview]
Message-ID: <20180629175641.13a2a747@redhat.com> (raw)
In-Reply-To: <94085ac5-0242-1cb5-065a-7e50183792bd@redhat.com>

On Fri, 29 Jun 2018 17:39:10 +0200
David Hildenbrand <david@redhat.com> wrote:

> On 29.06.2018 16:49, Igor Mammedov wrote:
> > 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?  
> 
> Sure we can do that, I wanted to match here exactly what has been
> written in the comment.
> 
> > 
> > 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).  
> 
> "To determine the size of a page and the allocation granularity on the
> host computer, use the GetSystemInfo" [1]
> 
> "The size of the region, in bytes. If the lpAddress parameter is NULL,
> this value is rounded up to the next page boundary. " [1]
> 
> Historically, this seems to be 64k. But it will always be at least 4k
> (page size). So what we could do is query the actual allocation granularity:
> 
> int get_allocation_granularity(void) {
> 	SYSTEM_INFO system_info;
> 
> 	GetSystemInfo(&system_info);
> 	return system_info.dwAllocationGranularity
> }
> 
> 
> "dwAllocationGranularity: The granularity for the starting address at
> which virtual memory can be allocated. For more information, see
> VirtualAlloc." [2]
> 
> What do you think?
maybe do following:

    *align = MAX(get_allocation_granularity(), getpagesize())

> 
> > 
> >   
> >> 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)  
> 
> Good point!
> 
> [1]
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx
> [2]
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724958(v=vs.85).aspx
> 

  reply	other threads:[~2018-06-29 15:56 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
2018-06-29 15:39     ` David Hildenbrand
2018-06-29 15:56       ` Igor Mammedov [this message]
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=20180629175641.13a2a747@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.