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

2017-09-28 Thread Jan Beulich
>>> On 27.09.17 at 19:02,  wrote:
> On 09/27/2017 11:10 AM, Roger Pau Monné wrote:
>> On Wed, Sep 27, 2017 at 02:26:37PM +, Jan Beulich wrote:
>> On 27.09.17 at 16:16,  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.

Hmm, but that's a problem which can't be resolved by changing
the calculation of how much memory to reserve, I would think.
I'm afraid I'm confused.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


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

2017-09-27 Thread Boris Ostrovsky
On 09/27/2017 11:10 AM, Roger Pau Monné wrote:
> On Wed, Sep 27, 2017 at 02:26:37PM +, Jan Beulich wrote:
> On 27.09.17 at 16:16,  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


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

2017-09-27 Thread Roger Pau Monné
On Wed, Sep 27, 2017 at 02:26:37PM +, Jan Beulich wrote:
> >>> On 27.09.17 at 16:16,  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.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


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

2017-09-27 Thread Jan Beulich
>>> On 27.09.17 at 16:16,  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.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel