Re: [Xen-devel] implementing memory ballooning in WIndows

[Steven Smith <steven.smith@xxxxxxxxxxxxx>]

> > > Do the Citrix Windows PV drivers implement memory ballooning? I've
> been
> > > looking at this a bit for GPLPV and the avenues I can see are:
> > >
> > > 1. Memory can be added via ACPI hot-add, but I assume that that
> isn't
> > > implemented in the GPL qemu code (or is it?) and only works for
> Windows
> > > Server Enterprise, not Vista, XP, or Server Standard.
> > > 2. I can give memory back via just allocating a physical page and
> giving
> > > it back to Xen
> > 
> > Our drivers do implement ballooning (although it's not actually hooked
> > up to the control tools, for mostly tedious reasons), and they do it
> > using approach 2.
> > 
> > Approach 1 does have the advantage that you can later increase a
> > domain's memory allocation beyond its boot-time size, but that's
> > obviated to some extent by the new populate-on-demand support, and, as
> > you say, memory hot add is quite heavily restricted by Microsoft's
> > licensing.
> > 
> 
> #2 is pretty much where I was going. My concern was that Windows says "I
> have 4GB of memory, so I can use X amount for this and Y amount for that
> and Z amount for something else", and when the memory is reduced down to
> (say) 1GB, I was worried that Windows might get a bit unbalanced. Same
> with Linux when it makes decisions about how much space to reserve for
> network buffers etc.
> 
> But it seems that you have taken the stance that there is no such
> problem, so I'll do the same.
We've gotten away with it so far, certainly.

> The other thing I was concerned about is that the memory is only given
> back once the PV drivers start, so in the situation where you have:
> . 16G physical memory
> . Dom0 with 2G of memory
> . 6 DomU's with 4G of memory, ballooned down to 2G of memory
> 
> It would only work if all the DomU's successfully ran their PV drivers
> and ballooned the memory down as requested, and you couldn't start them
> all at once as on boot they'd actually need 4G of memory.
Well, the second problem is solved by populate-on-demand mode.  The
first is much harder, and almost certainly requires some kind of
emergency hypervisor paging.

Of course, if you do populate-on-demand and then *can't* balloon down
then the failure mode is extremely bad.  It can hopefully be avoided
by a sufficiently paranoid toolstack, but it's still rather
unfortunate.

> Did you ever have a tinker with the (mostly) undocumented
> MmAddPhysicalMemory function at all? On face value it seems like it is
> the sort of function that could be useful... Microsoft would not approve
> of such a thing obviously which makes it unusable for production use,
> but I am curious as to if it would actually work.
I've not looked at it at all, sorry.

Steven.

Attachment: signature.asc
Description: Digital signature

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