Re: Is: PVH - how to solve maxmem != memory scenario? Was:Re: [PATCH] libxl: create PVH guests with max memory assigned

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Aug 05, 2014 at 04:12:39PM +0100, Jan Beulich wrote:
> >>> On 05.08.14 at 16:48, <konrad.wilk@oracle.com> wrote:
> > On Tue, Aug 05, 2014 at 03:36:19PM +0100, Jan Beulich wrote:
> >> >>> On 05.08.14 at 16:18, <konrad.wilk@oracle.com> wrote:
> >> > Mukesh's feeling was that it is an PV.
> >> > 
> >> > I believe George is the opinion of 'HVM' without the device model.
> >> 
> >> I think we settled already that this is the intended long term model.
> >> However, what's wrong with having the kernel act PV-like on top of
> >> a PoD-based hypervisor implementation. Simply not touching the
> >> memory amount beyond the initial allocation would already make
> >> things work afaict, i.e. even without any decrease-reservation
> >> calls (and it would therefore desirable but mostly cosmetic to get
> >> them done as early as possible).
> > 
> > Linux sets its page-tables (beyound the bootstrap) using an interesting
> > mechanism which ends up touching those pages.
> > 
> > Bear with the explanation as it is a bit complex.
> > 
> > When it setups page-tables for a new range of memory (1GB
> > or 2MB, or 4KB ranges - in PVH it will likely be in 2GB
> > since the 1GB cpuid parameter is not exposed), it ends up
> > populating the L2, L3, and L4 (as needed) from the earlier
> > range. When it is done with this range (say 2MB), it will
> > put the page table entries in the physical area of the newly
> > added region.
> > 
> > Something like this:
> > 
> >     +--------------------------------------+                     
> >     |                                      v                     
> >     |   2MB region------------->|<------  2MB region ---------->
> > +---+------+--------------------+----------+--------------------+
> > |          |                    |          |                    |
> > |pgtable   |                    |pgtable   |                    |
> > +----------+--------------------+----------+--------------------+
> > 
> > 
> > In effect the pages beyound 'memory' will be touched during bootup.
> 
> I don't think that's how it works, as this wouldn't leave any
> contiguous 2M pages for allocation. I think the block sizes are

Ah right.

> much larger, and what memblock_find_in_range() returns isn't
> necessarily always from the most recently added block I'd
> suppose.

That sounds right. The logic in there is to expand the region
for the pagetables in the range as possible. And then when it
can't use it anymore - it will jump to the next one. This is all
from memory when I reviewed it years ago so take this with a grain
of salt please.
> 
> Jan
>