[Xen-devel] Re: PoD issue

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

So did you track down where the math error is?  Do we have a plan to fix 
this going forward?
-George

Jan Beulich wrote:
> > > > George Dunlap  01/29/10 7:30 PM >>>
> > > >         
> > PoD is not critical to balloon out guest memory.  You can boot with mem 
> > == maxmem and then balloon down afterwards just as you could before, 
> > without involving PoD.  (Or at least, you should be able to; if you 
> > can't then it's a bug.)  It's just that with PoD you can do something 
> > you've always wanted to do but never knew it: boot with 1GiB with the 
> > 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 
> > it?  (i.e., 2^30 vs 10^9?)  The difference between 1GiB (2^30) and 1 GB 
> > (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 
> > balloon driver, but we rely on it to have the same model of how to 
> > 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
>
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel