From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH] libxl: create PVH guests with max memory assigned Date: Tue, 5 Aug 2014 13:08:22 +0200 Message-ID: <53E0BB26.6050507@citrix.com> References: <1405594942-20760-1-git-send-email-roger.pau@citrix.com> <1407228940.2120.22.camel@kazak.uk.xensource.com> <53E0A538.608@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XEcbT-0003hf-4S for xen-devel@lists.xenproject.org; Tue, 05 Aug 2014 11:08:27 +0000 In-Reply-To: <53E0A538.608@citrix.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: David Vrabel , Ian Campbell Cc: xen-devel@lists.xenproject.org, Ian Jackson List-Id: xen-devel@lists.xenproject.org On 05/08/14 11:34, David Vrabel wrote: > On 05/08/14 09:55, Ian Campbell wrote: >> On Thu, 2014-07-17 at 13:02 +0200, Roger Pau Monne wrote: >> >> Sorry for the delay replying, this somehow slipped through my net. >> >>> Since PVH guests are very similar to HVM guests in terms of memory >>> management, start the guest with the maximum memory assigned and let >>> it balloon down. >> >> Both before and after this patch an HVM guest would be launched with >> target_memkb though, not max_memkb (presumably relying on PoD), so the >> comparison made in the commit log doesn't tally to me given that you are >> making PVH (and only PVH) use max_memkb. >> >> This patch seems to make it impossible to boot a PVH guest >> pre-ballooned. It only appears to "work" because I presume you actually >> have enough RAM to satisfy maxmem for a short time, but that defeats the >> purpose. >> >> Either a PVH guest is similar enough to an HVM guest in this area to >> make use of PoD for early ballooning *or* it is similar enough to a PV >> guest that it can use the PV kernel entry point to get in early enough >> to initialise the balloon driver (via the XEN_EXTRA_MEM_MAX_REGIONS >> stuff, I presume) before the kernels normal init sequence can start >> mucking with that memory. Yes, now that I look at it again I realize the patch is completely wrong. > A decision on which needs to be made and /documented/. If the PV-like > approach is taken, I won't be accepting any Linux patches without such > documentation. > > I now regret accepting the PVH support in Linux without a clear > specification of what PVH actually is. I've always thought of PVH as PVHVM without a device model, so IMHO it would make more sense to use PoD rather than the PV ballooning approach, but I would like to hear opinions from others before taking a stab into implementing it. Roger.