From: Andrea Arcangeli <aarcange@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH QEMU] Transparent Hugepage Support #3
Date: Wed, 17 Mar 2010 16:35:22 +0100 [thread overview]
Message-ID: <20100317153522.GC5752@random.random> (raw)
In-Reply-To: <201003171521.26911.paul@codesourcery.com>
On Wed, Mar 17, 2010 at 03:21:26PM +0000, Paul Brook wrote:
> > On Wed, Mar 17, 2010 at 03:05:57PM +0000, Paul Brook wrote:
> > > > + if (size >= PREFERRED_RAM_ALIGN)
> > > > + new_block->host = qemu_memalign(PREFERRED_RAM_ALIGN,
> > > > size);
> > >
> > > Is this deliberately bigger-than rather than multiple-of?
> > > Having the size not be a multiple of alignment seems somewhat strange,
> > > it's always going to be wrong at one end...
> >
> > Size not multiple I think is legitimate, the below-4G chunk isn't
> > required to end 2M aligned, all it matters is that the above-4G then
> > starts aligned. In short one thing to add in the future as parameter
> > to qemu_ram_alloc is the physical address that the host virtual
> > address corresponds to.
>
> In general you don't know this at allocation time.
Caller knows it, it's not like the caller is outside of qemu, it's not
some library. We know this is enough with the caller that there is now.
Again there is absolutely no relation between the "size" and
this. Size can be anything and it's absolutely irrelevant.
All it matter is the _start_. Both the guest physical address _start_
and the host virtual address _start_. And they don't have to be
aligned to 2M, simply their alignment or misalignment have to match
and this is the simplest way to have them match.
> > The guest physical address that the host
> > retval corresponds to, has to be aligned with PREFERRED_RAM_ALIGN for
> > NPT/EPT to work. I don't think it's a big concern right now.
>
> If you allocating chinks that are multiples of the relevant page size, then I
> don't think you can expect anything particularly sensible to happen.
If you want me to do a bigger more complex patch that passes down to
qemu_ram_alloc the actual guest physical address that the virtual
address returned by qram_mem_alloc will correspond to, I will do
it. That likely would be something like qemu_ram_alloc_align.
And if somebody volunteers to avoid me to do it, you're welcome.
I don't care how this happens but it must happen.
next prev parent reply other threads:[~2010-03-17 15:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-17 14:59 [Qemu-devel] [PATCH QEMU] Transparent Hugepage Support #3 Andrea Arcangeli
2010-03-17 15:05 ` Paul Brook
2010-03-17 15:14 ` Andrea Arcangeli
2010-03-17 15:21 ` Paul Brook
2010-03-17 15:35 ` Andrea Arcangeli [this message]
2010-03-17 15:52 ` Paul Brook
2010-03-17 15:55 ` Andrea Arcangeli
2010-03-17 16:07 ` Paul Brook
2010-03-17 16:23 ` Andrea Arcangeli
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=20100317153522.GC5752@random.random \
--to=aarcange@redhat.com \
--cc=avi@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/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).