From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: PoD issue Date: Sun, 31 Jan 2010 17:48:14 +0000 Message-ID: <4B65C25E02000078000584AB@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: george.dunlap@eu.citrix.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> George Dunlap 01/29/10 7:30 PM >>> >PoD is not critical to balloon out guest memory. You can boot with = mem=20 >=3D=3D maxmem and then balloon down afterwards just as you could = before,=20 >without involving PoD. (Or at least, you should be able to; if you=20 >can't then it's a bug.) It's just that with PoD you can do something=20 >you've always wanted to do but never knew it: boot with 1GiB with the=20 >option of expanding up to 2GiB later. :-) Oh, no, that's not what I meant. What I really wanted to say is that with PoD, a properly functioning balloon driver in the guest is crucial for it to stay alive long enough. >With the 54 megabyte difference: It's not like a GiB vs GB thing, is=20 >it? (i.e., 2^30 vs 10^9?) The difference between 1GiB (2^30) and 1 = GB=20 >(10^9) is about 74 megs, or 18,000 pages. No, that's not the problem. As I understand it now, the problem is that totalram_pages (which the balloon driver bases its calculations on) reflects all memory available after all bootmem allocations were done (i.e. includes neither the static kernel image nor any memory allocated before or from the bootmem allocator). >I guess that is a weakness of PoD in general: we can't control the = guest=20 >balloon driver, but we rely on it to have the same model of how to=20 >translate "target" into # pages in the balloon as the PoD code. I think this isn't a weakness of PoD, but a design issue in the balloon driver's xenstore interface: While a target value shown in or obtained from the /proc and /sys interfaces naturally can be based on (and reflect) any internal kernel state, the xenstore interface should only use numbers in terms of full memory amount given to the guest. Hence a target value read from the memory/target node should be adjusted before put in relation to totalram_pages. And I think this is a general misconception in the current implementation (i.e. it should be corrected not only for the HVM case, but for the pv one as well). The bad aspect of this is that it will require a fixed balloon driver in any HVM guest that has maxmem>mem when the underlying Xen gets updated to a version that supports PoD. I cannot, however, see an OS and OS-version independent alternative (i.e. something to be done in the PoD code or the tools). Jan