Features and fixes:
  - HVM mode is supported now,
  - migration from mod_timer() to schedule_delayed_work(),
  - removal of driver_pages (I do not have seen any
    references to it),
  - protect before CPU exhaust by event/x process during
    errors by adding some delays in scheduling next event,
  - some other minor fixes.

Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
---
 arch/x86/xen/mmu.c    |    3 +-
 drivers/xen/balloon.c |  128 +++++++++++++++++++++++++++++++++----------------
 2 files changed, 87 insertions(+), 44 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 42086ac..6278650 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -75,8 +75,7 @@
 
 /*
  * Protects atomic reservation decrease/increase against concurrent increases.
- * Also protects non-atomic updates of current_pages and driver_pages, and
- * balloon lists.
+ * Also protects non-atomic updates of current_pages and balloon lists.
  */
 DEFINE_SPINLOCK(xen_reservation_lock);
 
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 500290b..06dbdad 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -69,14 +69,11 @@ struct balloon_stats {
 	/* We aim for 'current allocation' == 'target allocation'. */
 	unsigned long current_pages;
 	unsigned long target_pages;
-	/*
-	 * Drivers may alter the memory reservation independently, but they
-	 * must inform the balloon driver so we avoid hitting the hard limit.
-	 */
-	unsigned long driver_pages;
 	/* Number of pages in high- and low-memory balloons. */
 	unsigned long balloon_low;
 	unsigned long balloon_high;
+	unsigned long schedule_delay;
+	unsigned long max_schedule_delay;
 };
 
 static DEFINE_MUTEX(balloon_mutex);
@@ -103,15 +100,14 @@ static LIST_HEAD(ballooned_pages);
 
 /* Main work function, always executed in process context. */
 static void balloon_process(struct work_struct *work);
-static DECLARE_WORK(balloon_worker, balloon_process);
-static struct timer_list ...
[ message continues ]

Each of those bullets should be a separate patch (or several if
appropriate). I didn't review most of the rest because it mixed so much

Is there some reason we need to override the compiler's decision here?

I don't think there is anything wrong with the existing style here.

Ian.


--

[ message continues ]

Hi,




I do not insist on applying this patch however, this notation
is more readable for me. I am not confused by
comma which suggest that next attribut follow it.

Daniel
--

[ message continues ]

--

[ message continues ]

On Mon, 27 Dec 2010 10:08:47 -0500, Konrad Rzeszutek Wilk

I have apply this patch to bare 2.6.36.2 kernel from kernel.org. If
memory=maxmemory pv guest run's on migrating fine.
If on already running domU i have xm mem-max xxx 1024 (before that it
has 768) and do xm mem-set 1024 guest now have 1024 memory, but after
that it can't migrate to another host.

Step to try to start guest with memory=512 and maxmemory=1024 it boot
fine, xm mem-set work's fine, but.. it can't migrate. Sorry but nothing
on screen , how can i help to debug this problem?
--

[ message continues ]

You can play with 'xenctx' to see where the guest is stuck. You can also
look in the 'xm dmesg' to see if there is something odd. Lastly, if you
mean by 'can't migrate to another host' as the command hangs stops, look
at the error code (or in /var/log/xen files) and also look in the source
--

[ message continues ]

On Mon, 27 Dec 2010 11:39:18 -0500, Konrad Rzeszutek Wilk

xm dmesg and /var/log/xen/* provide nothing useful. can't migrate meand
- xm migrate --live start migration process, on destination node domain
constucted all memory copied and after that in xentop picture like this:
1) some second after migration xentop displays line like this:

test_domain -----r          2  109.8     262144    0.4    1048576      
1.7    14    1        0        0    2        0        0        0        
0          0    0

2) after that some second line changed to this:

test_domain ---c--          3  245.6     262144    0.4    1048576      
1.7    14    1        0        0    2        0        0        0        
0          0    0

3) after some milli seconds:

test_domain ---cp-          3    0.0     111460    0.2    1048576      
1.7    14    1        0        0    2        0        0        0        
0          0    0

4) after 2 or 3 seconds like this:

test_domain d--cp-          3    0.0          4    0.0    1048576      
1.7    14    1        0        0    2        0        0        0        
0          0    0

after step 4 domain is crushed. If i don't use Daniel's patch - this
not happening.
--

[ message continues ]

Hi,



I will try to investigate that problem. Could you send me as much
info as possible about that issue (Xen version, kernel version,
config files, log files, etc.) ???

Daniel
--

[ message continues ]

I think it would be good to have it for xen/stable-2.6.32.x aswell!
(that's the tree that's used the most atm).

-- Pasi

--

[ message continues ]

In general we are hoping to move development of new features to more
recent upstream versions and become increasingly conservative with what
gets taken into the 2.6.32.x branch.

If we think a particular feature is worth having for 2.6.32.x then I
think it would be worth getting them upstream and stabilised before

But what is the demand for this particular functionality among the users
of that tree who cannot or will not switch to a more recent upstream?
Bearing in mind that this is primarily a domU feature and that domU
support is well established upstream.

Ian.


--

[ message continues ]

Hi,



This is in seconds. Initial delay is 1 s.
It could not be greater than 32 s.
I think that those values are good for
default config because they provide good
resposivnes of balloon process and protect
before CPU exhaust by it during erros.
However, if those values are not acceptable
by user he/she could change them using sysfs.

Daniel
--

[ message continues ]