Currently, if the dom0_nodes parameter is used, to limit the hard or
soft affinity of dom0's vCPUs, the boot hangs. This is because the vCPU
affinity is set in two steps, and is only correct after we've done both.
Credit2, however, manages to see and use the result of the first one and
vCPUs are put on pCPUs where they can't run.

This has been reported here:
https://bugzilla.suse.com/show_bug.cgi?id=1197081

And a fix has been discussed in the thread of this message:
https://lore.kernel.org/xen-devel/e061a647cd77a36834e2085a96a07caa785c5066.camel@suse.com/

The solution adopted in this series is to change the vCPU affinity
setting code in such a way that it happens alltogether and in one place
(patch 2).

While there, make the dom0_vcpus_pin boot parameter more precise, by
making sure that it is applied only to actual dom0's vCPUs, and not to
the vCPUs of the hardware domain, which may or may not be dom0 itself
(patch 2).

Regards
---
Dario Faggioli (2):
      xen: sched: dom0_vcpus_pin should only affect dom0
      xen/sched: setup dom0 vCPUs affinity only once


 xen/common/sched/core.c | 63 +++++++++++++++++++++++++----------------
 1 file changed, 39 insertions(+), 24 deletions(-)
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)