From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH] libxc: refactor memory allocation functions Date: Tue, 1 Dec 2015 12:12:36 +0000 Message-ID: <20151201121236.GQ21588@citrix.com> References: <1448969956-26310-1-git-send-email-wei.liu2@citrix.com> <1448971124.15768.117.camel@citrix.com> <565D8CBE.9020001@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a3jnX-00045z-JN for xen-devel@lists.xenproject.org; Tue, 01 Dec 2015 12:12:43 +0000 Content-Disposition: inline In-Reply-To: <565D8CBE.9020001@suse.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: Juergen Gross Cc: Ian Jackson , Xen-devel , Wei Liu , Ian Campbell List-Id: xen-devel@lists.xenproject.org On Tue, Dec 01, 2015 at 01:04:14PM +0100, Juergen Gross wrote: > On 01/12/15 12:58, Ian Campbell wrote: > > On Tue, 2015-12-01 at 11:39 +0000, Wei Liu wrote: > >> There were some problems with the original memory allocation functions: > >> 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling > >> xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything. > >> 2. xc_dom_alloc_pad didn't call dom->allocate. > >> > >> Refactor the code so that: > >> 1. xc_dom_alloc_{segment,pad,page} end up calling > >> xc_dom_chk_alloc_pages. > >> 2. xc_dom_chk_alloc_pages calls dom->allocate. > >> > >> This way we avoid scattering dom->allocate over multiple locations and > >> open-coding. > >> > >> Also change the return type of xc_dom_alloc_page to xen_pfn_t and return > >> an invalid pfn when xc_dom_chk_alloc_pages fails. > > > > Given this presumably the handful of callers ought to gain some error > > handling in a followup patch? > > I could do that. Wei? > You're welcome to pick that up. > > > > xc_dom_chk_alloc_pages does log, so at least the callers needn't bother > > with that. > > > >> Signed-off-by: Wei Liu > > > > Acked-by: Ian Campbell > > > >> --- > >> Cc: Ian Campbell > >> Cc: Ian Jackson > >> Cc: Juergen Gross > >> > >> We don't have INVALID_PFN, maybe we need one? > > > > We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the > > bill (or if not how it is distinct from the former). > > What about merging all of them into INVALID_FRAME? > Note that INVALID_MFN is in public header (xenctrl.h) while INVALID_P2M_ENTRY is not. In fact (xen_pfn_t)-1 is part of guest ABI so we should properly export and document it. The current situation is not ideal. Not sure how much yak shaving is required though. Wei. > I can create a patch(-series). > > > Juergen >