Re: (auto-)ballooning issue

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.01.2026 12:14, Roger Pau Monné wrote:
> On Tue, Aug 26, 2025 at 05:28:29PM +0200, Jan Beulich wrote:
>> Hello,
>>
>> the other day I observed a strange issue with XTF's selftest failing to
>> have its VMs created, when running all flavors in a group. (Other tests
>> look to be similarly affected, it's just the selftest that I run most
>> frequently.) Originally I suspected a PVH-specific issue, but the
>> problem surfacing only there is because with PVH Dom0 I have less free
>> memory left after boot than with PV Dom0. Beyond that, both
>> configurations use the same hypervisor, with built-in DOM0_MEM="-255M".
>>
>> The issue looks to be further affected (but not caused) by domain
>> cleanup being quite a bit slower under PVH Dom0, compared to PV. I.e.
>> by the time the 2nd test is started, memory from the 1st one still
>> wasn't completely freed. The result is that randomly one of the latter
>> (batched) tests fails at domain creation ("failed to free memory for
>> the domain").
>>
>> xl's freemem() calls libxl_set_memory_target() followed by
>> libxl_wait_for_memory_target(). The latter function expects the domain
>> to balloon down enough for its ->tot_pages (in the hypervisor) to be
>> at or below the previously set target. However, already immediately
>> after boot "xl list -l" and "xs ls /" show target values which are 1
>> page below the hypervisor's record. With libxl_set_memory_target()
>> requesting relative adjustment, the Dom0 kernel will balloon out the
>> requested number of pages, but ->tot_pages going down by as many pages
>> isn't enough to please libxl_wait_for_memory_target().
>>
>> I'm not even close to having an opinion as to where the problem is: It
>> could be that the kernel's balloon driver is off by a page. I'm more
>> inclined though to think that it is entirely unrealistic to expect the
>> kernel's balloon driver and Xen to have an exactly matching view of
>> the memory owned by the domain. Yet then it is simply invalid to
>> compare values taken from Xenstore against values taken from Xen. While
>> problematic for absolute requests, for relative ones it should be
>> possible apply the decrement to the source later used to compare
>> against while waiting.
> 
> Little late, sorry.  I think:
> 
> xen/balloon: improve accuracy of initial balloon target for dom0
> https://lore.kernel.org/xen-devel/20260128110510.46425-3-roger.pau@xxxxxxxxxx/
> 
> Might improve the situation here, as it should make the dom0 initial
> balloon target match what the toolstack expects, and then
> (auto-)ballooning targets should also be accurate w.r.t. the memory
> freed by dom0.

Just to confirm (finally got around to it) - both patches together indeed
eliminate the observed anomaly.

Jan