RE: [Xen-devel] Re: [PATCH] Disable auto-balloon on ia64

RE: [Xen-devel] Re: [PATCH] Disable auto-balloon on ia64

[Tian, Kevin]

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2006年5月22日 17:51
>To: Keir Fraser
>
>>> 	We just need to reverse the whole change for ia64, since both
>domU
>>> and domVTI are insert a hole by this auto-balloon patch. Due to
>>> missing balloon support on xen/ia64 as you said, both domU and
>domVTI
>>> failed due to this change.
>>
>> The first patch that you work around seems okay to me. That is, it
>> seems correct that we make initial reservation exclude
>> 'getDomainMemory headroom'. Shouldn't ia64 reserve extra memory
>as it
>> needs it, as x86 does,  rather than up front?
>>
>> The second bit of your workaround, which applies to
>getDomainMemory:
>> I'll wait and see if Charles has anything to say, but otherwise I'll
>> remove the code that adds the extra slack entirely.
>
>Thinking about it, that slack might have been added to give enough
>space for shadow page tables for live migration. Also, it shouldn't
>give you any problems if you weren't allocating headroom up front -- if
>you can fix ia64 to allocate the extra memory as needed then you
>shouldn't need either of your workarounds?
>
>  -- Keir

OK, the question by far is that ia64 describes the memory hierarchy 
presented to domain by d->max_pages. Before balloon is ready, we at 
least need to ensure all frames covered by d->max_pages allocated for 
target domain. Then there're two alternatives:
	- Keep the first piece of change on increase_reservation, which 
ensures all pages including extra spaces allocated immediately.
	- Pass the extra memory size to xen at arch_set_info_guest, and 
then change xen/ia64 to only tell domain maximum pfns as 
d->max_pages-extra_size

Both need to be changed again later if balloon is ready. So I prefer to 
option I which is simpler and can help Alex to do sync quickly. How do 
you think?

Thanks,
Kevin

RE: Re: [PATCH] Disable auto-balloon on ia64

[Alex Williamson]

On Mon, 2006-05-22 at 21:33 +0800, Tian, Kevin wrote:
> OK, the question by far is that ia64 describes the memory hierarchy 
> presented to domain by d->max_pages. Before balloon is ready, we at 
> least need to ensure all frames covered by d->max_pages allocated for 
> target domain. Then there're two alternatives:
> 	- Keep the first piece of change on increase_reservation, which 
> ensures all pages including extra spaces allocated immediately.
> 	- Pass the extra memory size to xen at arch_set_info_guest, and 
> then change xen/ia64 to only tell domain maximum pfns as 
> d->max_pages-extra_size
> 
> Both need to be changed again later if balloon is ready. So I prefer to 
> option I which is simpler and can help Alex to do sync quickly. How do 
> you think?

   I agree, I think we can get by with only the ia64 changes in the
increase_reservation call.  The other option seems more fragile.  Keir,
would you include the first chunk of Kevin's patch as a temporary
solution until we have better ballooning support on xen/ia64 (should be
soon)?  Thanks,

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab

[PATCH] Disable auto-balloon on ia64

[Tian, Kevin]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

>From: Alex Williamson
>Sent: 2006年5月22日 6:30
>
>On Sun, 2006-05-21 at 15:07 -0600, Alex Williamson wrote:
>> diff -r 4dcb93547710 tools/python/xen/xend/image.py
>> --- a/tools/python/xen/xend/image.py	Sun May 21 09:55:15 2006
>+0100
>> +++ b/tools/python/xen/xend/image.py	Sun May 21 14:25:19 2006
>-0600
>> @@ -146,7 +146,7 @@ class ImageHandler:
>>          """@return The memory required, in KiB, by the domain to
>store the
>>          given amount, also in KiB.  This is normally just mem, but if
>HVM is
>>          supported, keep a little extra free."""
>> -        if 'hvm' in xc.xeninfo()['xen_caps']:
>> +        if 'hvm' in xc.xeninfo()['xen_caps'] and os.uname()[4] !=
>'ia64':
>>              mem_kb += 4*1024;
>>          return mem_kb
>
>   Looks like this is just a partial solution, VTi guests are still
>broken with only this change.  Instead, we probably need to look at cset
>10040.  I suspect we don't yet have the ballooning support and need to
>do the allocation up front.  Thanks,
>
>	Alex

	We just need to reverse the whole change for ia64, since both domU and domVTI are insert a hole by this auto-balloon patch. Due to missing balloon support on xen/ia64 as you said, both domU and domVTI failed due to this change.

	Patch attached.

Thanks,
Kevin

[-- Attachment #2: fix-auto-balloon.patch --]
[-- Type: application/octet-stream, Size: 1824 bytes --]

Following auto-balloon doesn't work for xen/ia64, since balloon
doesn't work yet. Patch's a bit dirty, which however promises ia64
domU and domVTI to boot again.

(Based on fix from Alex)
Signed-off-by Kevin Tian <kevin.tian@intel.com>
diff -r 14717dedba02 tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py	Sun May 21 20:15:58 2006 +0100
+++ b/tools/python/xen/xend/XendDomainInfo.py	Mon May 22 16:43:48 2006 +0800
@@ -29,6 +29,7 @@ import string
 import string
 import time
 import threading
+import os
 
 import xen.lowlevel.xc
 from xen.util import asserts
@@ -1264,8 +1265,10 @@ class XendDomainInfo:
             m = self.image.getDomainMemory(self.info['memory'] * 1024)
             balloon.free(m)
             xc.domain_setmaxmem(self.domid, m)
-            xc.domain_memory_increase_reservation(self.domid, self.info['memory'] * 1024, 0, 0)
-
+            if os.uname()[4]!='ia64':
+                xc.domain_memory_increase_reservation(self.domid, self.info['memory'] * 1024, 0, 0)
+            else:
+                xc.domain_memory_increase_reservation(self.domid, m, 0, 0)
             self.createChannels()
 
             channel_details = self.image.createImage()
diff -r 14717dedba02 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Sun May 21 20:15:58 2006 +0100
+++ b/tools/python/xen/xend/image.py	Mon May 22 16:43:48 2006 +0800
@@ -146,7 +146,7 @@ class ImageHandler:
         """@return The memory required, in KiB, by the domain to store the
         given amount, also in KiB.  This is normally just mem, but if HVM is
         supported, keep a little extra free."""
-        if 'hvm' in xc.xeninfo()['xen_caps']:
+        if 'hvm' in xc.xeninfo()['xen_caps'] and os.uname()[4]!='ia64':
             mem_kb += 4*1024;
         return mem_kb
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Disable auto-balloon on ia64

[Keir Fraser]

On 22 May 2006, at 10:06, Tian, Kevin wrote:

> 	We just need to reverse the whole change for ia64, since both domU 
> and domVTI are insert a hole by this auto-balloon patch. Due to 
> missing balloon support on xen/ia64 as you said, both domU and domVTI 
> failed due to this change.

The first patch that you work around seems okay to me. That is, it 
seems correct that we make initial reservation exclude 'getDomainMemory 
headroom'. Shouldn't ia64 reserve extra memory as it needs it, as x86 
does,  rather than up front?

The second bit of your workaround, which applies to getDomainMemory: 
I'll wait and see if Charles has anything to say, but otherwise I'll 
remove the code that adds the extra slack entirely.

  -- Keir

Re: Re: [PATCH] Disable auto-balloon on ia64

[Keir Fraser]

On 22 May 2006, at 10:37, Keir Fraser wrote:

>> 	We just need to reverse the whole change for ia64, since both domU 
>> and domVTI are insert a hole by this auto-balloon patch. Due to 
>> missing balloon support on xen/ia64 as you said, both domU and domVTI 
>> failed due to this change.
>
> The first patch that you work around seems okay to me. That is, it 
> seems correct that we make initial reservation exclude 
> 'getDomainMemory headroom'. Shouldn't ia64 reserve extra memory as it 
> needs it, as x86 does,  rather than up front?
>
> The second bit of your workaround, which applies to getDomainMemory: 
> I'll wait and see if Charles has anything to say, but otherwise I'll 
> remove the code that adds the extra slack entirely.

Thinking about it, that slack might have been added to give enough 
space for shadow page tables for live migration. Also, it shouldn't 
give you any problems if you weren't allocating headroom up front -- if 
you can fix ia64 to allocate the extra memory as needed then you 
shouldn't need either of your workarounds?

  -- Keir