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 10:48:44 -0400 Message-ID: <20140805144844.GK13057@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XEg2t-0006JO-I2 for xen-devel@lists.xenproject.org; Tue, 05 Aug 2014 14:48:59 +0000 Content-Disposition: inline In-Reply-To: <53E108030200007800029845@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 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. > > Jan >