From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: [PATCH V15 5/9] xen: Make gpfn related memops
 compatible with wider return values
Date: Sat, 25 Apr 2015 21:54:39 +0500
Message-ID: <553BC6CF.4070002@citrix.com>
References: <1429542384-23905-1-git-send-email-tklengyel@sec.in.tum.de>
	<1429542384-23905-6-git-send-email-tklengyel@sec.in.tum.de>
	<553519B5.8090202@citrix.com> <1429622611.4743.83.camel@citrix.com>
	<5536777B0200007800074579@mail.emea.novell.com>
	<1429626293.4743.115.camel@citrix.com>
	<55367AD702000078000745C0@mail.emea.novell.com>
	<CABfawhm2vFQDR2qzyisoMefVVNSTsrzePX2OjA6mt5S8cSe_PA@mail.gmail.com>
	<5536853F02000078000746EA@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5536853F02000078000746EA@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>, Tamas K Lengyel <tklengyel@sec.in.tum.de>
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>, Keir Fraser <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

Hi Jan,

On 21/04/2015 20:13, Jan Beulich wrote:
> For this specific one - is there a reasonable use case? Other than
> for host PFN, we have control over guest ones, and I'm not sure
> managing a guest with GPFNs extending past 4 billion can be
> expected to work if only this one hypercall got fixed. IOW I'm
> expecting to NAK any such addition without proper rationale.

There is hardware coming out with 48 bits address support (i.e 36 bit pfn).

Even though the current layout of 64bit address space is using 40 bits 
IPA, I wouldn't be surprise if we decide to extend it soon (I have in 
mind PCI passthrough).

Without this new hypercall, you rule out the possibility to run the 
toolstack (included memaccess or any software requiring the maximum PFN 
used by a domain) in a 32bit domain or 32bit userspace on 64bit domain.

I don't have a good use case, but I don't see why we should omit a such 
possibility. It would be better if we can fix now rather than waiting 
until someone need it.

Regards,

-- 
Julien Grall