[PATCH] x86/pod: Do not fragment PoD memory allocations

[Elliott Mitchell <ehem+xen@xxxxxxx>]

Previously p2m_pod_set_cache_target() would fall back to allocating 4KB
pages if 2MB pages ran out.  This is counterproductive since it suggests
severe memory pressure and is likely a precursor to a memory exhaustion
panic.  As such don't try to fill requests for 2MB pages from 4KB pages
if 2MB pages run out.

Signed-off-by: Elliott Mitchell <ehem+xen@xxxxxxx>

---
Changes in v2:
- Include the obvious removal of the goto target.  Always realize you're
  at the wrong place when you press "send".

I'm not including a separate cover message since this is a single hunk.
This really needs some checking in `xl`.  If one has a domain which
sometimes gets started on different hosts and is sometimes modified with
slightly differing settings, one can run into trouble.

In this case most of the time the particular domain is most often used
PV/PVH, but every so often is used as a template for HVM.  Starting it
HVM will trigger PoD mode.  If it is started on a machine with less
memory than others, PoD may well exhaust all memory and then trigger a
panic.

`xl` should likely fail HVM domain creation when the maximum memory
exceeds available memory (never mind total memory).

For example try a domain with the following settings:

memory = 8192
maxmem = 2147483648

If type is PV or PVH, it will likely boot successfully.  Change type to
HVM and unless your hardware budget is impressive, Xen will soon panic.

Really, this is an example of where Xen should be robust against user
error.  Certainly as a HVM domain this is wrong, yet a nominally valid
domain configuration shouldn't be able to panic Xen.

In other news, I would suggest on ia32 Xen should only support domain
memory allocations in multiples of 2MB.  There is need to toss around 4KB
pages for I/O and ballooning superpages may be difficult.  Yet allocating
or deallocating less than an entire superpage worth at a time seems
dubious.
---
 xen/arch/x86/mm/p2m-pod.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 48e609d1ed..1baa1404e8 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -212,16 +212,13 @@ p2m_pod_set_cache_target(struct p2m_domain *p2m, unsigned 
long pod_target, int p
             order = PAGE_ORDER_2M;
         else
             order = PAGE_ORDER_4K;
-    retry:
         page = alloc_domheap_pages(d, order, 0);
         if ( unlikely(page == NULL) )
         {
-            if ( order == PAGE_ORDER_2M )
-            {
-                /* If we can't allocate a superpage, try singleton pages */
-                order = PAGE_ORDER_4K;
-                goto retry;
-            }
+            /* Superpages allocation failures likely indicate severe memory
+            ** pressure.  Continuing to try to fulfill attempts using 4KB pages
+            ** is likely to exhaust memory and trigger a panic.  As such it is
+            ** NOT worth trying to use 4KB pages to fulfill 2MB page 
requests.*/
 
             printk("%s: Unable to allocate page for PoD cache (target=%lu 
cache=%ld)\n",
                    __func__, pod_target, p2m->pod.count);
-- 
2.20.1

-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445