CA-422187: fix NUMA on XS8

[mg12]

On XS8 we always raise an exception when attempting to claim from a single node.
We wanted to only use soft affinity when the single node claim succeeded (which is the correct fix on XS9, where this API is available). However this meant that we've effectively completely disabled NUMA support on XS8, without any way to turn it on.

Always use soft affinity when the single-node claim API is unavailable, this should keep NUMA working on XS8.

On XS9 Xen itself would never raise ENOSYS (it has a err = errno = 0 on ENOSYS).

Fixes: fb66dfc ("CA-421847: set vcpu affinity if node claim succeeded")

---

tested with:

• job 4526247 XS8: numaEnabledSerialStart on build toolstack-ci-watch/289611 containing fb66dfc: fails as expected
• job 4526243 XS8: numaEnabledSerialStart on build ca-422187/289733 containing 677c539: succeeds as expected:

(XEN) [  868.165388] NODE0 start->0 size->17301504 free->1491212
(XEN) [  868.165391] NODE1 start->17301504 size->16777216 free->1238913
(XEN) [  868.165393] CPU0...39 -> NODE0
(XEN) [  868.165395] CPU40...79 -> NODE1
(XEN) [  868.165396] Memory location of each domain:
(XEN) [  868.165400] Domain 0 (total: 1933312):
(XEN) [  868.173626]     Node 0: 872292
(XEN) [  868.173627]     Node 1: 1061020
(XEN) [  868.173633] Domain 7 (total: 14068987):
(XEN) [  868.232568]     Node 0: 14068987
(XEN) [  868.232569]     Node 1: 0
(XEN) [  868.232573] Domain 8 (total: 14068987):
(XEN) [  868.291207]     Node 0: 0
(XEN) [  868.291208]     Node 1: 14068987

[MarkSymsCtx]

@mg12 do we also need to run the test on XS9 to ensure that it still works correctly there as well. It should but better to verify explicitly.

[mg12]

this PR is to untangle XS8 only. If we need, we can add a further patch for XS9.

[MarkSymsCtx]

this PR is to untangle XS8 only. If we need, we can add a further patch for XS9.

that wasn't what I said. I said that we should verify that this has no unexpected consequences on XS9. We believe it should not given that XS9's Xen should not report ENOSYS but dur diligence we recommend doing verification tests.

[edwintorok]

this PR is to untangle XS8 only. If we need, we can add a further patch for XS9.

that wasn't what I said. I said that we should verify that this has no unexpected consequences on XS9. We believe it should not given that XS9's Xen should not report ENOSYS but dur diligence we recommend doing verification tests.

On XS9 there are a lot more things that are broken.
For XS9 I've been running tests using the private/edvint/hardclaim branch, which contains this branch + a lot of other XAPI and Xen fixes that are required to make the same test pass on XS9, the latest run of that was all green. Not sure that XS9 would work with just this patch (or in fact without this patch), we'll likely hit one of the N bugs about reservations/claims not working properly (reservations/claims don't exist on XS8, and hence why it works), but we can try.