[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] libxl: create PVH guests with max memory assigned

On 05/08/14 11:34, David Vrabel wrote:
> On 05/08/14 09:55, Ian Campbell wrote:
>> On Thu, 2014-07-17 at 13:02 +0200, Roger Pau Monne wrote:
>> Sorry for the delay replying, this somehow slipped through my net.
>>> Since PVH guests are very similar to HVM guests in terms of memory
>>> management, start the guest with the maximum memory assigned and let
>>> it balloon down.
>> Both before and after this patch an HVM guest would be launched with
>> target_memkb though, not max_memkb (presumably relying on PoD), so the
>> comparison made in the commit log doesn't tally to me given that you are
>> making PVH (and only PVH) use max_memkb.
>> This patch seems to make it impossible to boot a PVH guest
>> pre-ballooned. It only appears to "work" because I presume you actually
>> have enough RAM to satisfy maxmem for a short time, but that defeats the
>> purpose.
>> Either a PVH guest is similar enough to an HVM guest in this area to
>> make use of PoD for early ballooning *or* it is similar enough to a PV
>> guest that it can use the PV kernel entry point to get in early enough
>> to initialise the balloon driver (via the XEN_EXTRA_MEM_MAX_REGIONS
>> stuff, I presume) before the kernels normal init sequence can start
>> mucking with that memory.

Yes, now that I look at it again I realize the patch is completely wrong.

> A decision on which needs to be made and /documented/.  If the PV-like
> approach is taken, I won't be accepting any Linux patches without such
> documentation.
> I now regret accepting the PVH support in Linux without a clear
> specification of what PVH actually is.

I've always thought of PVH as PVHVM without a device model, so IMHO it
would make more sense to use PoD rather than the PV ballooning approach,
but I would like to hear opinions from others before taking a stab into
implementing it.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.