lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXC1sFjIRUEB7qOW@Mac.lan>
Date: Wed, 21 Jan 2026 12:17:04 +0100
From: Roger Pau Monné <roger.pau@...rix.com>
To: Jason Andryuk <jason.andryuk@....com>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
	James Dingwall <james@...gwall.me.uk>,
	Juergen Gross <jgross@...e.com>,
	Stefano Stabellini <sstabellini@...nel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target
 initialization for PVH dom0"

On Tue, Jan 20, 2026 at 03:10:06PM -0500, Jason Andryuk wrote:
> On 2026-01-20 09:06, Roger Pau Monne wrote:
> > This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so
> > the current memory target for PV guests is still fetched from
> > start_info->nr_pages, which matches exactly what the toolstack sets the
> > initial memory target to.
> > 
> > Using get_num_physpages() is possible on PV also, but needs adjusting to
> > take into account the ISA hole and the PFN at 0 not considered usable
> > memory depite being populated, and hence would need extra adjustments.
> > Instead of carrying those extra adjustments switch back to the previous
> > code.  That leaves Linux with a difference in how current memory target is
> > obtained for HVM vs PV, but that's better than adding extra logic just for
> > PV.
> > 
> > Also, for HVM the target is not (and has never been) accurately calculated,
> > as in that case part of what starts as guest memory is reused by hvmloader
> > and possibly other firmware to store ACPI tables and similar firmware
> > information, thus the memory is no longer being reported as RAM in the
> > memory map.
> > 
> > Reported-by: James Dingwall <james@...gwall.me.uk>
> > Signed-off-by: Roger Pau Monné <roger.pau@...rix.com>
> 
> Reviewed-by: Jason Andryuk <jason.andryuk@....com>

Thanks.

I've been considering what we discussed and as a separate follow up we
might want to attempt to switch to using `XENMEM_current_reservation`
for dom0?  It might make the accounting in PVH dom0 better, as that's
what the toolstack uses to set the xenstore target when initializing
dom0 values.

Regards, Roger.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ