Re: [Xen-devel] [PATCH] increase initial memory reservation for stubdom based HVM domains

["Trolle Selander" <trolle.selander@xxxxxxxxx>]

For what it's worth, the discussion on qemu-devel is leaning towards not having a hardcoded limit to the amount of assignable vram, and that more than xres * yres * 4 bytes or vram can in fact be useful for a guest. We can of course still enforce a limit - I'd raise it to 32 Megs, taking double-buffering into consideration. Regardless of the arguments on qemu-devel, i think the practical use of any more vram than that is questionable to say the least - but depending on how closely we want to stay in sync with upstream qemu this should perhaps the at least be taken into consideration. 

-- Trolle

On Thu, Jan 15, 2009 at 12:59 PM, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:

Samuel Thibault wrote:

> Keir Fraser, le Thu 15 Jan 2009 17:34:26 +0000, a écrit :
>> Doesn't stubdom itself cause the auto-ballooner to be run?
>
> Yes. (and the issue was that here the auto-ballooner doesn't know that
> qemu hasn't taken the 8MB extra ballooned memory for video memory yet)
>
>> Could stubdom add on the extra headroom of the guest its servicing
>> when it requests ballooning? I don't know whether that would be
>> clearer/cleaner than your current patch...
>
> I don't know how that could be done, but it seems better to me.
>

It can be done: instead of requesting 16MB for the videoram (or whatever
is set in the config file) when we create the HVM domain, we request
them when we create the stubdom.
It also seems to me that this approach is cleaner, I'll try to come up
with a patch.

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

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