[PATCH] x86/shadow: adjust minimum allocation calculations

[PATCH] x86/shadow: adjust minimum allocation calculations

[Jan Beulich]

A previously bad situation has become worse with the early setting of
->max_vcpus: The value returned by shadow_min_acceptable_pages() has
further grown, and hence now holds back even more memory from use for
the p2m.

Make sh_min_allocation() account for all p2m memory needed for
shadow_enable() to succeed during domain creation (at which point the
domain has no memory at all allocated to it yet, and hence use of
d->tot_pages is meaningless).

Also make shadow_min_acceptable_pages() no longer needlessly add 1 to
the vCPU count.

Finally make the debugging printk() in shadow_alloc_p2m_page() a little
more useful by logging some of the relevant domain settings.

Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
TBD: The question of course is whether such an "exact" calculation isn't
     a little risky going forward, the more that the regression here
     wasn't found by osstest, because domains with sufficiently few
     vCPU-s weren't affected, due to the 4Mb minimum allocation enforced
     by shadow_enable()'s call to shadow_set_allocation(). I would,
     however, question this enforcement of a static minimum as well -
     shadow_one_bit_enable() doesn't do so, for example.

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -966,7 +966,8 @@ const u8 sh_type_to_size[] = {
     1  /* SH_type_oos_snapshot   */
 };
 
-/* Figure out the least acceptable quantity of shadow memory.
+/*
+ * Figure out the least acceptable quantity of shadow memory.
  * The minimum memory requirement for always being able to free up a
  * chunk of memory is very small -- only three max-order chunks per
  * vcpu to hold the top level shadows and pages with Xen mappings in them.
@@ -975,11 +976,11 @@ const u8 sh_type_to_size[] = {
  * instruction, we must be able to map a large number (about thirty) VAs
  * at the same time, which means that to guarantee progress, we must
  * allow for more than ninety allocated pages per vcpu.  We round that
- * up to 128 pages, or half a megabyte per vcpu, and add 1 more vcpu's
- * worth to make sure we never return zero. */
+ * up to 128 pages, or half a megabyte per vcpu.
+ */
 static unsigned int shadow_min_acceptable_pages(const struct domain *d)
 {
-    return (d->max_vcpus + 1) * 128;
+    return d->max_vcpus * 128;
 }
 
 /* Dispatcher function: call the per-mode function that will unhook the
@@ -1322,8 +1323,11 @@ shadow_alloc_p2m_page(struct domain *d)
         if ( !d->arch.paging.p2m_alloc_failed )
         {
             d->arch.paging.p2m_alloc_failed = 1;
-            dprintk(XENLOG_ERR, "d%i failed to allocate from shadow pool\n",
-                    d->domain_id);
+            dprintk(XENLOG_ERR,
+                    "d%d failed to allocate from shadow pool (tot=%u p2m=%u min=%u)\n",
+                    d->domain_id, d->arch.paging.shadow.total_pages,
+                    d->arch.paging.shadow.p2m_pages,
+                    shadow_min_acceptable_pages(d));
         }
         paging_unlock(d);
         return NULL;
@@ -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);
 }
 
 int shadow_set_allocation(struct domain *d, unsigned int pages, bool *preempted)




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

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

[Roger Pau Monné]

On Wed, Feb 06, 2019 at 03:56:49AM -0700, Jan Beulich wrote:
> A previously bad situation has become worse with the early setting of
> ->max_vcpus: The value returned by shadow_min_acceptable_pages() has
> further grown, and hence now holds back even more memory from use for
> the p2m.
> 
> Make sh_min_allocation() account for all p2m memory needed for
> shadow_enable() to succeed during domain creation (at which point the
> domain has no memory at all allocated to it yet, and hence use of
> d->tot_pages is meaningless).
> 
> Also make shadow_min_acceptable_pages() no longer needlessly add 1 to
> the vCPU count.
> 
> Finally make the debugging printk() in shadow_alloc_p2m_page() a little
> more useful by logging some of the relevant domain settings.
> 
> Reported-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> TBD: The question of course is whether such an "exact" calculation isn't
>      a little risky going forward, the more that the regression here
>      wasn't found by osstest, because domains with sufficiently few
>      vCPU-s weren't affected, due to the 4Mb minimum allocation enforced
>      by shadow_enable()'s call to shadow_set_allocation(). I would,
>      however, question this enforcement of a static minimum as well -
>      shadow_one_bit_enable() doesn't do so, for example.

I wondered the same while doing my fix, whether it was best to account
for the exact amount of pages needed for shadow_enable to succeed, or
whether to add a fixed amount of slack that was greater than the
actual requirements of shadow_enable.

Since you have done the accounting, and I expect shadow_enable to not
change it's memory requirements very often I guess we can go with the
exact amount for now.

> 
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -966,7 +966,8 @@ const u8 sh_type_to_size[] = {
>      1  /* SH_type_oos_snapshot   */
>  };
>  
> -/* Figure out the least acceptable quantity of shadow memory.
> +/*
> + * Figure out the least acceptable quantity of shadow memory.
>   * The minimum memory requirement for always being able to free up a
>   * chunk of memory is very small -- only three max-order chunks per
>   * vcpu to hold the top level shadows and pages with Xen mappings in them.
> @@ -975,11 +976,11 @@ const u8 sh_type_to_size[] = {
>   * instruction, we must be able to map a large number (about thirty) VAs
>   * at the same time, which means that to guarantee progress, we must
>   * allow for more than ninety allocated pages per vcpu.  We round that
> - * up to 128 pages, or half a megabyte per vcpu, and add 1 more vcpu's
> - * worth to make sure we never return zero. */
> + * up to 128 pages, or half a megabyte per vcpu.
> + */
>  static unsigned int shadow_min_acceptable_pages(const struct domain *d)
>  {
> -    return (d->max_vcpus + 1) * 128;
> +    return d->max_vcpus * 128;
>  }
>  
>  /* Dispatcher function: call the per-mode function that will unhook the
> @@ -1322,8 +1323,11 @@ shadow_alloc_p2m_page(struct domain *d)
>          if ( !d->arch.paging.p2m_alloc_failed )
>          {
>              d->arch.paging.p2m_alloc_failed = 1;
> -            dprintk(XENLOG_ERR, "d%i failed to allocate from shadow pool\n",
> -                    d->domain_id);
> +            dprintk(XENLOG_ERR,
> +                    "d%d failed to allocate from shadow pool (tot=%u p2m=%u min=%u)\n",
> +                    d->domain_id, d->arch.paging.shadow.total_pages,
> +                    d->arch.paging.shadow.p2m_pages,
> +                    shadow_min_acceptable_pages(d));
>          }
>          paging_unlock(d);
>          return NULL;
> @@ -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.

Thanks, Roger.

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

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

[Andrew Cooper]

On 06/02/2019 10:56, 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.

What is in slot 0?  Nothing comes to mind.

>       */
> -    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) +

I'm not sure cpu_has_vmx is the right check here.  For one, there is a
series posted adding similar support for AMD, so this is going to be
stale shortly.

I'd err on the side of making it unconditional, but if you do want to be
as tight as possible, then cpu_has_vmx_apic_reg_virt is the correct
check for now.

~Andrew

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

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

[Jan Beulich]

>>> On 06.02.19 at 13:00, <andrew.cooper3@citrix.com> wrote:
> On 06/02/2019 10:56, 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.
> 
> What is in slot 0?  Nothing comes to mind.

I can only refer you to p2m_alloc_table(), which has

    /* Initialise physmap tables for slot zero. Other code assumes this. */
    p2m->defer_nested_flush = 1;
    rc = p2m_set_entry(p2m, _gfn(0), INVALID_MFN, PAGE_ORDER_4K,
                       p2m_invalid, p2m->default_access);
    p2m->defer_nested_flush = 0;

>>       */
>> -    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) +
> 
> I'm not sure cpu_has_vmx is the right check here.  For one, there is a
> series posted adding similar support for AMD, so this is going to be
> stale shortly.
> 
> I'd err on the side of making it unconditional, but if you do want to be
> as tight as possible, then cpu_has_vmx_apic_reg_virt is the correct
> check for now.

Well, if anything then the qualifier vmx_alloc_vlapic_mapping() uses,
which is cpu_has_vmx_virtualize_apic_accesses (unless you tell me
that needs changing too). But if SVM is going to have a similar
requirement going forward, then making it unconditional is fine with
me.

Jan



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

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

[Jan Beulich]

>>> On 06.02.19 at 12:52, <roger.pau@citrix.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Roger Pau Monné]

On Wed, Feb 06, 2019 at 05:53:16AM -0700, Jan Beulich wrote:
> >>> On 06.02.19 at 12:52, <roger.pau@citrix.com> 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@citrix.com>

Thanks, Roger.

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

[PATCH v2] x86/shadow: adjust minimum allocation calculations

[Jan Beulich]

A previously bad situation has become worse with the early setting of
->max_vcpus: The value returned by shadow_min_acceptable_pages() has
further grown, and hence now holds back even more memory from use for
the p2m.

Make sh_min_allocation() account for all p2m memory needed for
shadow_enable() to succeed during domain creation (at which point the
domain has no memory at all allocated to it yet, and hence use of
d->tot_pages is meaningless).

Also make shadow_min_acceptable_pages() no longer needlessly add 1 to
the vCPU count.

Finally make the debugging printk() in shadow_alloc_p2m_page() a little
more useful by logging some of the relevant domain settings.

Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
v2: Drop cpu_has_vmx dependency (to cover future SVM code as well).
---
TBD: The question of course is whether such an "exact" calculation isn't
     a little risky going forward, the more that the regression here
     wasn't found by osstest, because domains with sufficiently few
     vCPU-s weren't affected, due to the 4Mb minimum allocation enforced
     by shadow_enable()'s call to shadow_set_allocation(). I would,
     however, question this enforcement of a static minimum as well -
     shadow_one_bit_enable() doesn't do so, for example.

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -966,7 +966,8 @@ const u8 sh_type_to_size[] = {
     1  /* SH_type_oos_snapshot   */
 };
 
-/* Figure out the least acceptable quantity of shadow memory.
+/*
+ * Figure out the least acceptable quantity of shadow memory.
  * The minimum memory requirement for always being able to free up a
  * chunk of memory is very small -- only three max-order chunks per
  * vcpu to hold the top level shadows and pages with Xen mappings in them.
@@ -975,11 +976,11 @@ const u8 sh_type_to_size[] = {
  * instruction, we must be able to map a large number (about thirty) VAs
  * at the same time, which means that to guarantee progress, we must
  * allow for more than ninety allocated pages per vcpu.  We round that
- * up to 128 pages, or half a megabyte per vcpu, and add 1 more vcpu's
- * worth to make sure we never return zero. */
+ * up to 128 pages, or half a megabyte per vcpu.
+ */
 static unsigned int shadow_min_acceptable_pages(const struct domain *d)
 {
-    return (d->max_vcpus + 1) * 128;
+    return d->max_vcpus * 128;
 }
 
 /* Dispatcher function: call the per-mode function that will unhook the
@@ -1322,8 +1323,11 @@ shadow_alloc_p2m_page(struct domain *d)
         if ( !d->arch.paging.p2m_alloc_failed )
         {
             d->arch.paging.p2m_alloc_failed = 1;
-            dprintk(XENLOG_ERR, "d%i failed to allocate from shadow pool\n",
-                    d->domain_id);
+            dprintk(XENLOG_ERR,
+                    "d%d failed to allocate from shadow pool (tot=%u p2m=%u min=%u)\n",
+                    d->domain_id, d->arch.paging.shadow.total_pages,
+                    d->arch.paging.shadow.p2m_pages,
+                    shadow_min_acceptable_pages(d));
         }
         paging_unlock(d);
         return NULL;
@@ -1373,9 +1377,13 @@ 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 an 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 + 2 : 0U) +
+           is_hvm_domain(d);
 }
 
 int shadow_set_allocation(struct domain *d, unsigned int pages, bool *preempted)




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

Re: [PATCH v2] x86/shadow: adjust minimum allocation calculations

[George Dunlap]

On Thu, Feb 7, 2019 at 11:42 AM Jan Beulich <JBeulich@suse.com> wrote:
>
> A previously bad situation has become worse with the early setting of
> ->max_vcpus: The value returned by shadow_min_acceptable_pages() has
> further grown, and hence now holds back even more memory from use for
> the p2m.
>
> Make sh_min_allocation() account for all p2m memory needed for
> shadow_enable() to succeed during domain creation (at which point the
> domain has no memory at all allocated to it yet, and hence use of
> d->tot_pages is meaningless).
>
> Also make shadow_min_acceptable_pages() no longer needlessly add 1 to
> the vCPU count.
>
> Finally make the debugging printk() in shadow_alloc_p2m_page() a little
> more useful by logging some of the relevant domain settings.
>
> Reported-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> v2: Drop cpu_has_vmx dependency (to cover future SVM code as well).
> ---
> TBD: The question of course is whether such an "exact" calculation isn't
>      a little risky going forward, the more that the regression here
>      wasn't found by osstest, because domains with sufficiently few
>      vCPU-s weren't affected, due to the 4Mb minimum allocation enforced
>      by shadow_enable()'s call to shadow_set_allocation(). I would,
>      however, question this enforcement of a static minimum as well -
>      shadow_one_bit_enable() doesn't do so, for example.

This whole thing could use some rationalization; but this will do for
now I think:

Acked-by: George Dunlap <george.dunlap@citrix.com.

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

Re: [PATCH v2] x86/shadow: adjust minimum allocation calculations

[Tim Deegan]

At 04:41 -0700 on 07 Feb (1549514492), Jan Beulich wrote:
> A previously bad situation has become worse with the early setting of
> ->max_vcpus: The value returned by shadow_min_acceptable_pages() has
> further grown, and hence now holds back even more memory from use for
> the p2m.
> 
> Make sh_min_allocation() account for all p2m memory needed for
> shadow_enable() to succeed during domain creation (at which point the
> domain has no memory at all allocated to it yet, and hence use of
> d->tot_pages is meaningless).
> 
> Also make shadow_min_acceptable_pages() no longer needlessly add 1 to
> the vCPU count.
> 
> Finally make the debugging printk() in shadow_alloc_p2m_page() a little
> more useful by logging some of the relevant domain settings.
> 
> Reported-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

I don't think it's worth bikeshedding too hard over individual
pages on this path; these numbers look OK.

Cheers,

Tim.


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

Re: [PATCH v2] x86/shadow: adjust minimum allocation calculations

[Juergen Gross]

On 07/02/2019 12:41, Jan Beulich wrote:
> A previously bad situation has become worse with the early setting of
> ->max_vcpus: The value returned by shadow_min_acceptable_pages() has
> further grown, and hence now holds back even more memory from use for
> the p2m.
> 
> Make sh_min_allocation() account for all p2m memory needed for
> shadow_enable() to succeed during domain creation (at which point the
> domain has no memory at all allocated to it yet, and hence use of
> d->tot_pages is meaningless).
> 
> Also make shadow_min_acceptable_pages() no longer needlessly add 1 to
> the vCPU count.
> 
> Finally make the debugging printk() in shadow_alloc_p2m_page() a little
> more useful by logging some of the relevant domain settings.
> 
> Reported-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Release-acked-by: Juergen Gross <jgross@suse.com>


Juergen

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