Re: [Xen-devel] [PATCH] x86/shadow: adjust minimum allocation calculations

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Feb 06, 2019 at 05:53:16AM -0700, Jan Beulich wrote:
> >>> On 06.02.19 at 12:52, <roger.pau@xxxxxxxxxx> wrote:
> > On Wed, Feb 06, 2019 at 03:56:49AM -0700, Jan Beulich wrote:
> >> @@ -1373,9 +1377,15 @@ static unsigned int sh_min_allocation(co
> >>  {
> >>      /*
> >>       * Don't allocate less than the minimum acceptable, plus one page per
> >> -     * megabyte of RAM (for the p2m table).
> >> +     * megabyte of RAM (for the p2m table, minimally enough for HVM's 
> >> setting
> >> +     * up of slot zero and VMX's setting up of the LAPIC page), plus one 
> >> for
> >> +     * HVM's 1-to-1 pagetable.
> >>       */
> >> -    return shadow_min_acceptable_pages(d) + (d->tot_pages / 256);
> >> +    return shadow_min_acceptable_pages(d) +
> >> +           max(d->tot_pages / 256,
> >> +               is_hvm_domain(d) ? CONFIG_PAGING_LEVELS + !!cpu_has_vmx * 2
> >> +                                : 0U) +
> >> +           is_hvm_domain(d);
> > 
> > Should the call to shadow_set_allocation be changed so it attempts to
> > allocate sh_min_allocation(d) + d->arch.paging.shadow.p2m_pages?
> > 
> > It seems a little misleading to check whether there's a certain amount
> > of pages in the pool (sh_min_allocation(d) +
> > d->arch.paging.shadow.p2m_pages) and then set the allocation to 4M
> > unconditionally.
> 
> Well, as said in the post-commit-message remark, I think we want to
> get rid of this, but only with it properly replaced (which would likely
> require hooking into paths increasing d->tot_pages). Right now all
> we're after is dealing with the regression.

Ack, with the changes requested by Andrew:

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel