| Message ID | 165952060175.13196.15449615309231718989.stgit@tumbleweed.Wayrath (mailing list archive) |
|---|---|
| Headers | show |
| Series | xen: credit2: fix boot hangs if dom0_nodes is used | expand |
On 03.08.2022 11:58, Dario Faggioli wrote: > Take 2 of this series. I think I've addressed Jan's comments. v1 was > Message-id: <165944775952.3531.14547627248752689801.stgit@tumbleweed.Wayrath> > > 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 I'll throw in this one, but ... > xen/sched: setup dom0 vCPUs affinity only once ... I'd like to give this a little for a Tested-by: Olaf to possibly arrive. Jan
Take 2 of this series. I think I've addressed Jan's comments. v1 was Message-id: <165944775952.3531.14547627248752689801.stgit@tumbleweed.Wayrath> 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)