From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH V15 5/9] xen: Make gpfn related memops compatible with wider return values Date: Mon, 27 Apr 2015 11:18:43 +0100 Message-ID: <553E0D03.2030003@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> <5536853F02000078000746EA@mail.emea.novell.com> <553BC6CF.4070002@citrix.com> <553DED2102000078000CDDEE@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <553DED2102000078000CDDEE@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , julien.grall@citrix.com, tklengyel@sec.in.tum.de Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, julien.grall@linaro.org, tim@xen.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.com, keir@xen.org, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org Hi Jan, On 27/04/2015 08:02, Jan Beulich wrote: >>>> Julien Grall 04/25/15 10:37 PM >>> >> 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. > > For a 32-bit domain, I suppose there are more limitations (unsigned long > being used for MFNs/PFNs), so I don't see how this one addition would > help. For 32-bit userspace on 64-bit domains the hypercall again isn't > the limiting factor, but the kernel's hypercall interface is. (And again I > doubt widening the MFN/PFN/GFN representation just here would > really make 32-bit userspace work on such large hosts.) On ARM 32/64 bits xen_pfn_t is defined as uint64_t. So I don't see any problem, unless the toolstack uses unsigned long which is already obviously wrong... Although, I still don't see why it prevents us to fix this hypercall... It's the first step to make the toolstack x86 agnostic (because unsigned long is x86 specific). Regards, -- Julien Grall