On 17.01.20 12:01, Jan Beulich wrote:
On 16.01.2020 18:00, Juergen Gross wrote:
Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
tried to fix a regression with running on rather ancient Xen versions.
Unfortunately the fix was based on the assumption that xend would
just use another Xenstore node, but in reality only some downstream
versions of xend are doing that. The upstream xend does not write
that Xenstore node at all, so the problem must be fixed in another
way.
The easiest way to achieve that is to fall back to the behavior before
commit 5266b8e4445c ("xen: fix booting ballooned down hvm guest")
in case the static memory maximum can't be read.
I could use some help here: Prior to said commit there was
target_diff = new_target - balloon_stats.target_pages;
Which is, afaict, ...
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -94,7 +94,7 @@ static void watch_target(struct xenbus_watch *watch,
"%llu", &static_max) == 1))
static_max >>= PAGE_SHIFT - 10;
else
- static_max = new_target;
+ static_max = balloon_stats.current_pages;
target_diff = (xen_pv_domain() || xen_initial_domain()) ? 0
: static_max - balloon_stats.target_pages;
... what the code does before your change. Afaict there was
never a use of balloon_stats.current_pages in this function.
That is a little bit indirect, yes. In the end I want static_max to
be either the maximum reported by Xen, or if not available, the current
assumed memory size, which can be found in balloon_stats.current_pages.
The main idea is to avoid a negative target_diff which would result in
not ballooning down.
Juergen
