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

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Tue, 5 Aug 2014 10:10:30 -0400
George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:

> 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.
...
> >>> 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.

It's tempting to go that way, but I think keeping PV model has a very
important conecptual benefit to xen. It allows us to modify the guest
OS for anything that could benefit it's performance on xen. That is 
something other hypervisors may not be able to do. So, at least for that
reason, I hope PVH can remain a PV, at least on the guest side.

> 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.

I forget also, I'll have to look at all that code again to refresh 
my memory.

thanks
Mukesh


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