Hello community,
here is the log from the commit of package xen for openSUSE:Leap:15.2 checked
in at 2020-03-31 07:21:34
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Leap:15.2/xen (Old)
and /work/SRC/openSUSE:Leap:15.2/.xen.new.3160 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen"
Tue Mar 31 07:21:34 2020 rev:84 rq:789168 version:4.13.0_11
Changes:
--------
--- /work/SRC/openSUSE:Leap:15.2/xen/xen.changes 2020-03-15
07:11:22.688963962 +0100
+++ /work/SRC/openSUSE:Leap:15.2/.xen.new.3160/xen.changes 2020-03-31
07:21:35.758377870 +0200
@@ -1,0 +2,14 @@
+Wed Mar 18 17:00:34 UTC 2020 - oher...@suse.de
+
+- bsc#1161480 - Fix xl shutdown for HVM without PV drivers
+ add libxl.libxl__domain_pvcontrol.patch
+
+-------------------------------------------------------------------
+Thu Mar 12 07:57:53 MDT 2020 - carn...@suse.com
+
+- bsc#1165206 - Xen 4.12 DomU hang / freeze / stall / NMI watchdog
+ bug soft lockup CPU #0 stuck under high load / upstream with
+ workaround. See also bsc#1134506
+ 01-xen-credit2-avoid-vcpus-to.patch
+
+-------------------------------------------------------------------
New:
----
01-xen-credit2-avoid-vcpus-to.patch
libxl.libxl__domain_pvcontrol.patch
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ xen.spec ++++++
--- /var/tmp/diff_new_pack.spoBt7/_old 2020-03-31 07:21:43.026381025 +0200
+++ /var/tmp/diff_new_pack.spoBt7/_new 2020-03-31 07:21:43.030381027 +0200
@@ -1,7 +1,7 @@
#
# spec file for package xen
#
-# Copyright (c) 2020 SUSE LINUX GmbH, Nuernberg, Germany.
+# Copyright (c) 2020 SUSE LLC
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
@@ -127,7 +127,7 @@
BuildRequires: pesign-obs-integration
%endif
-Version: 4.13.0_10
+Version: 4.13.0_11
Release: 0
Summary: Xen Virtualization: Hypervisor (aka VMM aka Microkernel)
License: GPL-2.0-only
@@ -200,6 +200,7 @@
Patch422: stubdom-have-iovec.patch
Patch423: vif-route.patch
Patch424: gcc10-fixes.patch
+Patch425: 01-xen-credit2-avoid-vcpus-to.patch
# Other bug fixes or features
Patch451: xenconsole-no-multiple-connections.patch
Patch452: hibernate.patch
@@ -216,6 +217,7 @@
Patch465: xen.libxl.dmmd.patch
Patch466: libxl.set-migration-constraints-from-cmdline.patch
Patch467: xenstore-run-in-studomain.patch
+Patch468: libxl.libxl__domain_pvcontrol.patch
Patch469: libxl.helper_done-crash.patch
Patch470: libxl.LIBXL_HOTPLUG_TIMEOUT.patch
# python3 conversion patches
@@ -443,6 +445,7 @@
%patch422 -p1
%patch423 -p1
%patch424 -p1
+%patch425 -p1
# Other bug fixes or features
%patch451 -p1
%patch452 -p1
@@ -459,6 +462,7 @@
%patch465 -p1
%patch466 -p1
%patch467 -p1
+%patch468 -p1
%patch469 -p1
%patch470 -p1
# python3 conversion patches
++++++ 01-xen-credit2-avoid-vcpus-to.patch ++++++
commit 149b5880db78648318b23623c93c6e4f91ad1e87
Author: Dario Faggioli <dfaggi...@suse.com>
Date: Wed Mar 11 19:13:59 2020 +0100
xen: credit2: avoid vCPUs to ever reach lower credits than idle
There have been report of stalls of guest vCPUs, when Credit2 was used.
It seemed like these vCPUs were not getting scheduled for very long
time, even under light load conditions (e.g., during dom0 boot).
Investigations led to the discovery that --although rarely-- it can
happen that a vCPU manages to run for very long timeslices. In Credit2,
this means that, when runtime accounting happens, the vCPU will lose a
large quantity of credits. This in turn may lead to the vCPU having less
credits than the idle vCPUs (-2^30). At this point, the scheduler will
pick the idle vCPU, instead of the ready to run vCPU, for a few
"epochs", which often times is enough for the guest kernel to think the
vCPU is not responding and crashing.
An example of this situation is shown here. In fact, we can see d0v1
sitting in the runqueue while all the CPUs are idle, as it has
-1254238270 credits, which is smaller than -2^30 = −1073741824:
(XEN) Runqueue 0:
(XEN) ncpus = 28
(XEN) cpus = 0-27
(XEN) max_weight = 256
(XEN) pick_bias = 22
(XEN) instload = 1
(XEN) aveload = 293391 (~111%)
(XEN) idlers: 00,00000000,00000000,00000000,00000000,00000000,0fffffff
(XEN) tickled:
00,00000000,00000000,00000000,00000000,00000000,00000000
(XEN) fully idle cores:
00,00000000,00000000,00000000,00000000,00000000,0fffffff
[...]
(XEN) Runqueue 0:
(XEN) CPU[00] runq=0, sibling=00,..., core=00,...
(XEN) CPU[01] runq=0, sibling=00,..., core=00,...
[...]
(XEN) CPU[26] runq=0, sibling=00,..., core=00,...
(XEN) CPU[27] runq=0, sibling=00,..., core=00,...
(XEN) RUNQ:
(XEN) 0: [0.1] flags=0 cpu=5 credit=-1254238270 [w=256] load=262144
(~100%)
We certainly don't want, under any circumstance, this to happen.
Therefore, let's use INT_MIN for the credits of the idle vCPU, in
Credit2, to be sure that no vCPU can get below that value.
NOTE: investigations have been done about _how_ it is possible for a
vCPU to execute for so long that its credits becomes so low. While still
not completely clear, there are evidence that:
- it only happens very rarely
- it appears to be both machine and workload specific
- it does not look to be a Credit2 (e.g., as it happens when running
with Credit1 as well) issue, or a scheduler issue
This patch makes Credit2 more robust to events like this, and should
hence be backported (as far as possible).
Signed-off-by: Dario Faggioli <dfaggi...@suse.com>
Reported-by: Glen <glenbar...@gmail.com>
Reported-by: Tomas Mozes <hydrapo...@gmail.com>
---
Cc: George Dunlap <george.dun...@citrix.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc: Charles Arnold <carn...@suse.com>
---
I will provide the backports myself, at least for 4.13 and 4.12.x (and
feel free to ask for more).
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index f7c477053c..2fe62466d5 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -232,7 +232,7 @@
* units does not consume credits, and it must be lower than whatever
* amount of credit 'regular' unit would end up with.
*/
-#define CSCHED2_IDLE_CREDIT (-(1U<<30))
+#define CSCHED2_IDLE_CREDIT INT_MIN
/*
* Carryover: How much "extra" credit may be carried over after
* a reset.
++++++ libxl.libxl__domain_pvcontrol.patch ++++++
References: bsc#1161480
Fix xl shutdown for HVM without PV drivers
A return value of zero means no PV drivers. Restore the hunk which was removed.
Fixes commit b183e180bce93037d3ef385a8c2338bbfb7f23d9
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/libxl/libxl_domain.c | 3 +++
1 file changed, 3 insertions(+)
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -765,24 +765,27 @@ char * libxl__domain_pvcontrol_read(libxl__gc *gc,
xs_transaction_t t,
int libxl__domain_pvcontrol(libxl__egc *egc, libxl__xswait_state *pvcontrol,
domid_t domid, const char *cmd)
{
STATE_AO_GC(pvcontrol->ao);
const char *shutdown_path;
int rc;
rc = libxl__domain_pvcontrol_available(gc, domid);
if (rc < 0)
return rc;
+ if (!rc)
+ return ERROR_NOPARAVIRT;
+
shutdown_path = libxl__domain_pvcontrol_xspath(gc, domid);
if (!shutdown_path)
return ERROR_FAIL;
rc = libxl__xs_printf(gc, XBT_NULL, shutdown_path, "%s", cmd);
if (rc)
return rc;
pvcontrol->path = shutdown_path;
pvcontrol->what = GCSPRINTF("guest acknowledgement of %s request", cmd);
pvcontrol->timeout_ms = 60 * 1000;
rc = libxl__xswait_start(gc, pvcontrol);
