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

[Julien Grall <julien.grall@citrix.com>]

Hi Jan,

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