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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Aug 5, 2014 at 7:08 AM, Roger Pau Monnà <roger.pau@xxxxxxxxxx> wrote:
> 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.

I think the original idea was to have PVH be PV with the addition of
an "HVM container" -- just a minimal bit of HVM that would allow us to
get rid of a lot of the unnecessary PV stuff.

But as it turned out, the "minimal HVM container" was 70% of the size
of the fully-virtualized HVM container.  Rather than have thousands of
lines of duplicate code, we decided to merge the HVM and PVH code
paths.  At which point, it makes more sense to just go the other
direction, and make PVH basically PVHVM without a device model.

I'm not sure how PV deals with memory != maxmem at boot: it seems like
PVH could do it the same way; or it could use PoD.  But just setting
memory=maxmem is certainly the wrong approach.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel