Re: [V10 PATCH 0/4] pvh dom0 patches...

[Mukesh Rathor <mukesh.rathor@oracle.com>]

On Wed, 7 May 2014 09:20:35 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Tue, May 06, 2014 at 06:00:53PM -0700, Mukesh Rathor wrote:
> > On Tue, 6 May 2014 09:13:08 +0200
> > Roger Pau Monné <roger.pau@citrix.com> wrote:
> > 
> > > On 06/05/14 02:28, Mukesh Rathor wrote:
> > > > On Mon, 5 May 2014 10:52:54 +0200
> > > > Roger Pau Monné <roger.pau@citrix.com> wrote:
> > ....
...
> > > Sure, that makes a lot of sense. What I was wondering is why
> > > don't we move the logic of "xen_populate_chunk" into Xen code
> > > itself, like we do for the holes part. If Xen is in charge of
> > > doing the holes in the memory map, it should also take care of
> > > adding those pages back to the end of the memory map, what we do
> > > right now is very awkward IMHO.
> > 
> > We don't because the guest needs to know the last pfn mapped. PV
> > guest starts with nr_pages as max pfn mapped and then walks the
> > e820 punching holes, keeping track of last_pfn etc... That code in
> > linux is a bit fragile, there is max_pfn, lastpfn, max_pages,
> > xen_start_info->nr_pages, extra_pages, to name a few! 
> > 
> > IOW, even if we did this in xen, guest would still need to have the
> > exact same code just to adjust it's last_pfn. That would be
> > dangerous if they go out of sync.
> 
> The Linux code already has that.
> > 
> > Dont' you already have all that logic for PV dom0? You would just
> > need to skip the p2m update.
> > 
> > Jan, 
> > 
> > As Konrad points out, there are other issues with that part of the
> > code. So, IMO, we should wait and address that altogether for both
> > PV and PVH, and for now leave this as is.
> > 
> > If you still feel we should do this in xen (as in required for this
> > patch series to go in), then we'd need to communicate last pfn to
> > guest. However, note that guest would still have all that code for
> > PV, for pvh we'd just skip it. Obvious way coming to mind is:
> > 
> > unsigned long last_pfn_mapped; 
> > 
> > added to struct start_info.  Alternative would be to add a 
> > new sub call to perhaps getdomaininfo hcall or something similar. 
> > Please lmk. 
> 
> Uh, why? The Linux generic code figures out the last_pfn by
> enumerating the E820. We only need 'max_pfn_mapped' in the P2M code
> to figure the top of the P2M array provided by us - so that we
> can use the extend_brk for anything above that- but that is
> flexible enough to deal with holes in the P2M and such.
> We also skip all of that when we run in the PVH mode.

Correct, if we do this in xen,  without Roger's second patch,
then enumerating e820 won't tell that. His second patch fixes that.

Mukesh

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