Re: [PATCH v6 02/23] xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 02/03/15 17:52, Ian Campbell wrote:
> 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?

If we were to go down that route, the toolstack would need a way of
signalling "this vNUMA node does not contain memory on a single pNUMA
node" if there was insufficient free space to make the allocation.

In this case, a pnode of XEN_NO_NUMA_NODE seems like precisely the
correct value to report.

~Andrew