Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0"

["Roger Pau Monné" <roger.pau@citrix.com>]

On Thu, Jan 22, 2026 at 09:40:01AM -0500, Jason Andryuk wrote:
> On 2026-01-21 12:49, Roger Pau Monné wrote:
> > I haven't tested it yet to see whether that's OK to do on PV, I would
> > think PV and PVH would be the same here, since the setting of the
> > xenstore target value is based in the return of
> > XENMEM_current_reservation for both.
> 
> On a system with 32GB and dom0=pvh dom0_mem=7G:
> 
> [    0.295201] xen:balloon: current_pages: 1835007 get_num_physpages 8220126
> xen_released_pages 6385120
> [    0.295201] ------------[ cut here ]------------
> [    0.295201] Released pages underflow current target
> 
> 8220126 - 6385120 = 1835006
> 
> And also for PV:
> 
> [    1.406923] xen:balloon: current_pages: 1835008 get_num_physpages 8220127
> xen_released_pages 6385120
> [    1.406928] ------------[ cut here ]------------
> [    1.406931] Released pages underflow current target
> 
> 
> So we don't want to subtract xen_released_pages for dom0.  Is
> xen_released_pages expected to be non-zero for a domU?

Oh, yes.  In fact I think the patch here is wrong for PV dom0, as it
shouldn't subtract xen_released_pages from xen_start_info->nr_pages.
I will need to send v2.

> IIRC, for a domU, xl writes the xenstore nodes as the ~build time memory
> value, which doesn't include video ram.  Later QEMU populates the videoram,
> which increases current reservation.  Then the two values don't match when
> the domU initializes the balloon values.

Yeah, the modifications done to the physmap by QEMU skew the target,
so what's in xenstore doesn't match what `XENMEM_current_reservation`
returns.  However is very hard to fix this.  We could attempt to make
the toolstack write the xenstore node based on the return of
XENMEM_current_reservation once QEMU has started.  Sadly a domU would
have no way to know whether the xenstore value accounts for the QEMU
consumed memory or not.  We would need to introduce a new target
xenstore node, which is equally messy.

Thanks for the testing.

Roger.