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

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



>>> 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.

Jan



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

 


Rackspace

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