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 <[email protected]> > > Signed-off-by: Roger Pau Monné <[email protected]> > > Reviewed-by: Jason Andryuk <[email protected]>
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.
