[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/pvh: fix PVHv2 Dom0 memory calculation



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.pau@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.