From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v6 02/23] xen: move NUMA_NO_NODE to public
 memory.h as XEN_NUMA_NO_NODE
Date: Mon, 2 Mar 2015 17:52:39 +0000
Message-ID: <1425318759.24959.49.camel@citrix.com>
References: <1424966166-2388-3-git-send-email-wei.liu2@citrix.com>
	<54F0AC920200007800064BFB@mail.emea.novell.com>
	<20150227165139.GF29195@zion.uk.xensource.com>
	<54F0A0DA.8020809@citrix.com>
	<54F40B7E02000078000C9AE2@mail.emea.novell.com>
	<1425310221.21151.87.camel@citrix.com>
	<20150302153814.GJ11855@zion.uk.xensource.com>
	<54F495190200007800065383@mail.emea.novell.com>
	<20150302160832.GM11855@zion.uk.xensource.com>
	<54F49D7D020000780006540C@mail.emea.novell.com>
	<20150302163918.GP11855@zion.uk.xensource.com>
	<54F4A2F80200007800065471@mail.emea.novell.com>
	<54F49777.3040506@citrix.com>
	<54F4AB4D02000078000654F0@mail.emea.novell.com>
	<54F49F36.10201@citrix.com>
	<54F4A153.4080504@citrix.com> <54F4A255.4040200@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <54F4A255.4040200@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: David Vrabel <david.vrabel@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On Mon, 2015-03-02 at 17:48 +0000, David Vrabel wrote:
> On 02/03/15 17:43, Andrew Cooper wrote:
> > On 02/03/15 17:34, David Vrabel wrote:
> >> 
> >> A guest that previously had 2 vNUMA nodes is migrated to a host with
> >> only 1 pNUMA node.  It should still have 2 vNUMA nodes.
> > 
> > A natural consequence of vNUMA is that the guest must expect the vNUMA
> > layout to change across suspend/resume.  The toolstack cannot guarentee
> > that it can construct a similar vNUMA layout after a migration.  This
> > includes the toolstack indicating that it was unable to make any useful
> > NUMA affinity with the memory ranges.
> 
> Eep!  I very much doubt we can do anything in Linux except retain the
> existing NUMA layout across a save/restore.

In the case you mention above I would expect the 2 vnuma nodes to just
point to the same single pnuma node.

As such I think it's probably not relevant to the need for
XEN_NO_NUMA_NODE?

Or is that not would be expected?