qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH QEMU] Transparent Hugepage Support #3


From: Andrea Arcangeli
Subject: Re: [Qemu-devel] [PATCH QEMU] Transparent Hugepage Support #3
Date: Wed, 17 Mar 2010 16:35:22 +0100

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]