[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Is: PVH - how to solve maxmem != memory scenario? Was:Re: [PATCH] libxl: create PVH guests with max memory assigned
On Tue, Aug 05, 2014 at 04:12:39PM +0100, Jan Beulich wrote: > >>> On 05.08.14 at 16:48, <konrad.wilk@xxxxxxxxxx> wrote: > > 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. > > 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 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |