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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
