Re: [Xen-devel] [PATCH V15 5/9] xen: Make gpfn related memops compatible with wider return values

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Jan,

On 27/04/2015 08:02, Jan Beulich wrote:
> > > > Julien Grall <julien.grall@xxxxxxxxxx> 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

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