On 09/27/2017 11:10 AM, Roger Pau Monné wrote: > On Wed, Sep 27, 2017 at 02:26:37PM +0000, Jan Beulich wrote: >>>>> On 27.09.17 at 16:16, <roger....@citrix.com> wrote: >>> --- a/xen/arch/x86/dom0_build.c >>> +++ b/xen/arch/x86/dom0_build.c >>> @@ -263,8 +263,7 @@ unsigned long __init dom0_compute_nr_pages( >>> avail -= max_pdx >> s; >>> } >>> >>> - need_paging = is_hvm_domain(d) && >>> - (!iommu_hap_pt_share || !paging_mode_hap(d)); >>> + need_paging = is_hvm_domain(d); >>> for ( ; ; need_paging = false ) >>> { >>> nr_pages = dom0_nrpages; >> Still in context above is the calculation for IOMMU page tables >> When iommu_hap_pt_share, why do we need to reserve extra >> space? If the IOMMU calculation isn't precise enough, perhaps >> that's what wants changing? Quite possibly it would suffice to >> simply double the value dom0_paging_pages() returns in that >> case. > I have not seen this issue myself, perhaps Boris can provide a little > more context on how to trigger this, so that the cause can be narrowed > down.
I could only trigger this on one of my machines but essentially the problem was that we reserved memory for page tables (pvh_setup_p2m()->paging_set_allocation()) and this reservation was not accounted for when trying to populate dom0's e820. -boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel