From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [V10 PATCH 0/4] pvh dom0 patches...
Date: Wed, 7 May 2014 09:25:19 -0400
Message-ID: <20140507132519.GB9190@phenom.dumpdata.com>
References: <5361049B.7040409@citrix.com>
	<20140430111216.2bef8e60@mantra.us.oracle.com>
	<20140430181923.68d75467@mantra.us.oracle.com>
	<53637BF3.2000502@citrix.com>
	<20140502170114.7ec2a9e6@mantra.us.oracle.com>
	<53675166.30400@citrix.com>
	<20140505172858.4c6c3f0a@mantra.us.oracle.com>
	<53688B84.8090607@citrix.com>
	<20140506180053.7c6da000@mantra.us.oracle.com>
	<536A01D8020000780000FB15@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Wi1qn-0002Oc-BG
	for xen-devel@lists.xenproject.org; Wed, 07 May 2014 13:25:33 +0000
Content-Disposition: inline
In-Reply-To: <536A01D8020000780000FB15@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: George.Dunlap@eu.citrix.com, tim@xen.org, keir.xen@gmail.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com
List-Id: xen-devel@lists.xenproject.org

On Wed, May 07, 2014 at 08:50:16AM +0100, Jan Beulich wrote:
> >>> On 07.05.14 at 03:00, <mukesh.rathor@oracle.com> wrote:
> > 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.
> 
> I'm fine either way, as long as you and Roger can reach agreement.
> I still tend towards considering Roger's position the right one as a
> mid/long term route.
> 
> > 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. 
> 
> We already have the max_pfn field in the shared info, which for
> PV is under the sole control of the guest kernel. That could
> certainly be set to other than zero to communicate what the
> highest mapped PFN is. The problem I'm seeing with this (and
> with everything you suggest above) is that this doesn't tell the
> guest where the holes are - while Dom0 can get at the machine
> memory map to tell (or really: guess) where they are, DomU can't
> yet will need to as soon as you want to be able to support device
> pass-through. Hence I guess we will need XENMEM_memory_map to
> reflect reality for PVH guests.

<nods> Right. And we can make it easier for the PVH guest if the M2P
and the Xen's P2M match the E820. For dom0 - meshing Roger's patch
in Mukesh should do it.

For the toolstack, well, that is a bit - there is code to create
E820's, but the code to setup the pagetables and such would need
to be written.

Or we can let the Linux guest do it as it has done for PV guests.
(Parse the E820, do the hypercalls to punch holes and add pages
back in).  For that thought the hypercalls it uses aren't correct
(I think - they didn't work for me in Xen 4.4) and that would need
some changes.

<sigh> Either way code has to be written somewhere to deal with this
for domU guests.

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