From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Is: PVH - how to solve maxmem != memory scenario? Was:Re: [PATCH] libxl: create PVH guests with max memory assigned Date: Tue, 5 Aug 2014 11:41:45 -0400 Message-ID: <20140805154145.GE19858@laptop.dumpdata.com> References: <1405594942-20760-1-git-send-email-roger.pau@citrix.com> <1407228940.2120.22.camel@kazak.uk.xensource.com> <53E0A538.608@citrix.com> <53E0BB26.6050507@citrix.com> <20140805141844.GG13057@laptop.dumpdata.com> <53E108030200007800029845@mail.emea.novell.com> <20140805144844.GK13057@laptop.dumpdata.com> <53E11087020000780002987E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XEgsB-0008RR-75 for xen-devel@lists.xenproject.org; Tue, 05 Aug 2014 15:41:59 +0000 Content-Disposition: inline In-Reply-To: <53E11087020000780002987E@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Ian Campbell , george.dunlap@eu.citrix.com, tim@xen.org, Ian Jackson , David Vrabel , xen-devel@lists.xenproject.org, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On Tue, Aug 05, 2014 at 04:12:39PM +0100, Jan Beulich wrote: > >>> On 05.08.14 at 16:48, wrote: > > On Tue, Aug 05, 2014 at 03:36:19PM +0100, Jan Beulich wrote: > >> >>> On 05.08.14 at 16:18, 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 >