From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH RESEND v2 2/2] xen: enable vnuma for PV guest Date: Tue, 19 Nov 2013 15:55:06 +0000 Message-ID: <528B89DA.2080504__37261.4852538847$1384876603$gmane$org@citrix.com> References: <1384811922-14642-1-git-send-email-ufimtseva@gmail.com> <1384811922-14642-3-git-send-email-ufimtseva@gmail.com> <528B5160.5010902@citrix.com> <20131119141620.GD5332@phenom.dumpdata.com> <528B774F.7090902@citrix.com> <20131119144630.GA5780@phenom.dumpdata.com> <528B7C29.3050103@citrix.com> <20131119151924.GC5790@phenom.dumpdata.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 1Vindx-00038q-33 for xen-devel@lists.xenproject.org; Tue, 19 Nov 2013 15:55:13 +0000 In-Reply-To: <20131119151924.GC5790@phenom.dumpdata.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: Konrad Rzeszutek Wilk Cc: akpm@linux-foundation.org, wency@cn.fujitsu.com, stefano.stabellini@eu.citrix.com, x86@kernel.org, linux-kernel@vger.kernel.org, tangchen@cn.fujitsu.com, mingo@redhat.com, Elena Ufimtseva , hpa@zytor.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, tglx@linutronix.de, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 19/11/13 15:19, Konrad Rzeszutek Wilk wrote: > On Tue, Nov 19, 2013 at 02:56:41PM +0000, David Vrabel wrote: >> The relevant bits in dummy_numa_init are in the error path of >> xen_numa_init(). > > That seems the wrong place to do it. The top layer calls > in each of the numa implementations and then falls back to > the dummy. Think of it as not the dummy, but Xen setting the NUMA configuration up with only a single node. The useful bits in dummy_numa_init() are two calls to standard functions for use by *_numa_init() calls so it just seems easier all round to just call then directly than add a dependancy on dummy_numa_init(). > Calling from within the implementation on something that is eventually > done on the upper level already is not right. >>From the point of view of the caller, it does the right thing. NUMA is setup. >> I do think this approach (using the provided API to setup the single >> (dummy) node), is preferable to calling dummy_numa_init(). > > Doesn't it do the same thing? And also what about if you the user > provides fakenuma? I don't know what "fakenuma" is refering to. >> If I thought the hypervisor ABI was finalized, I'd be happy with this >> series as-is -- the remaining issues are superficial. > > That reads to me as an Ack, but I know you like to have it stated > explicitly - so could you state the proper tag please? "If I thought the hypervisor ABI was finalized..." is a pretty big "if" so I have deliberately /not/ given an ack or a reviewed tag but I've tried to be clear than I think the Linux side is now good enough (except for any changes for any updates to the hypervisor ABI). David