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.
