Is: PVH - how to solve maxmem != memory scenario? Was:Re: [PATCH] libxl: create PVH guests with max memory assigned

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Aug 05, 2014 at 01:08:22PM +0200, Roger Pau Monné 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.

It is evolving :-)
> 
> 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.

Lets rope Mukesh, Tim, George and Jan in here.

Mukesh's feeling was that it is an PV.

I believe George is the opinion of 'HVM' without the device model.

In the past I  was thinking that since it is from the PV it would
be more of that (PV) without the P2M and M2P. And the memory management
(so E820) would follow the PV paths and do the proper ballooning/decreasing.

However I think it was you (David) who suggested that we just
setup the E820 properly in the toolstack/hypervisor and have it
match the hypervisors' P2M. That I believe is what Roger's patch
was aiming at.

A bit of past history:
Mukesh's initial patches (v3, see https://lkml.org/lkml/2012/10/17/553,
and https://lkml.org/lkml/2013/12/12/627, for new hypercall)
took the path that the PV guest will act as PV. And it will do
the proper hypercalls to expand/contract the Xen's P2M to balloon
out and in. However the only reason for this was to match
the P2M (assuming it was flat and up to nr_pages) to E820
(which would be discontingous) and setup the correct EPT entries
in the hypervisor.

My personal opinion is that the easiest path is the best.
If it is just the matter of making Xen's P2M and E820 be exactly
the same and let the Linux guest figure out based on 'nr_pages'
how many RAM pages are really provided), is the way, then
lets do it that way.

> 
> Roger.
>