From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 3/4] libxc: rework vnuma bits in setup_guest Date: Wed, 3 Jun 2015 11:57:33 +0100 Message-ID: <1433329053.7108.67.camel@citrix.com> References: <1433153954-27994-1-git-send-email-wei.liu2@citrix.com> <1433153954-27994-4-git-send-email-wei.liu2@citrix.com> <556CBE14.3010509@oracle.com> <1433327689.7108.62.camel@citrix.com> <20150603103917.GB12468@zion.uk.xensource.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 1Z06Od-0002Sx-3H for xen-devel@lists.xenproject.org; Wed, 03 Jun 2015 10:59:43 +0000 In-Reply-To: <20150603103917.GB12468@zion.uk.xensource.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: Wei Liu Cc: Xen-devel , Boris Ostrovsky , Ian Jackson , Dario Faggioli List-Id: xen-devel@lists.xenproject.org On Wed, 2015-06-03 at 11:39 +0100, Wei Liu wrote: > On Wed, Jun 03, 2015 at 11:34:49AM +0100, Ian Campbell wrote: > > On Mon, 2015-06-01 at 16:18 -0400, Boris Ostrovsky wrote: > > > On 06/01/2015 06:19 AM, Wei Liu wrote: > > > > Make the setup process similar to PV counterpart. That is, to allocate a > > > > P2M array that covers the whole memory range and start from there. This > > > > is clearer than using an array with no holes in it. > > > > > > > > Also the dummy layout should take MMIO hole into consideration. We might > > > > end up having two vmemranges in the dummy layout. > > > > > > > > Signed-off-by: Wei Liu > > > > Cc: Ian Campbell > > > > Cc: Ian Jackson > > > > > > Reviewed-by: Boris Ostrovsky > > > > + my ack on all 4 -> applied. > > > > > with a couple of nits below that you might consider. > > > > These can be done in followups, so I applied. > > > > I have a passing comment on one of the nits: > > > > > > + for ( vmemid = 0; vmemid < args->nr_vmemranges; vmemid++ ) > > > > + { > > > > + uint64_t pfn; > > > > + > > > > + for ( pfn = args->vmemranges[vmemid].start >> PAGE_SHIFT; > > > > + pfn < args->vmemranges[vmemid].end >> PAGE_SHIFT; > > > > + pfn++ ) > > > > + page_array[pfn] = pfn; > > > > + } > > > > > > > > /* > > > > * Try to claim pages for early warning of insufficient memory available. > > > > @@ -645,6 +679,12 @@ static int setup_guest(xc_interface *xch, > > > > error_out: > > > > rc = -1; > > > > out: > > > > + if ( use_dummy ) > > > > > > Or 'if (args->vmemranges == dummy_vmemrange)' and drop use_dummy variable. > > > > FWIW a more normal approach would be to do all the calculations on local > > variables and propagate them to the caller in the !use_dummy case. I > > don't know if that implies some huge restructure of this function > > though. > > There is no calculation with regard to vNUMA that needs to be propagated > to the caller in !use_dummy case. So this point is moot. The code returns with args->{nr_vnodes,vmemranges,vnode_to_pnode} having been updated, if that information should not be propoagated to the caller then surely it should be blown away irrespective of the dummy or not (and in that case why is it being done in that struct at all and not in some local variables freed on exit)