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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Aug 05, 2014 at 03:36:19PM +0100, Jan Beulich wrote:
> >>> On 05.08.14 at 16:18, <konrad.wilk@xxxxxxxxxx> 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.

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel