Re: [Xen-devel] [PATCH v8 04/15] xen: add function for obtaining highest possible memory address

[Juergen Gross <jgross@xxxxxxxx>]

On 20/09/17 11:32, Jan Beulich wrote:
>>>> On 20.09.17 at 10:58, <jgross@xxxxxxxx> wrote:
>> On 20/09/17 10:57, Jan Beulich wrote:
>>>>>> On 20.09.17 at 08:34, <jgross@xxxxxxxx> wrote:
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -6312,6 +6312,17 @@ int pv_ro_page_fault(unsigned long addr, struct 
>> cpu_user_regs *regs)
>>>>      return 0;
>>>>  }
>>>>  
>>>> +unsigned long arch_get_upper_mfn_bound(void)
>>>> +{
>>>> +    unsigned long max_mfn;
>>>> +
>>>> +    max_mfn = mem_hotplug ? PFN_DOWN(mem_hotplug) : max_page;
>>>
>>> Taking into account the code in the caller of this function as well
>>> as the ARM counterpart I find the use of max_page here odd. I'd
>>> prefer if get_upper_mfn_bound() went away altogether, and it's
>>> sole caller (which strangely enough doesn't get introduced here)
>>> called the arch function directly. Additionally, with the caller being
>>> a sysctl, how is that supposed to help a PV DomU kernel in their
>>> choice of grant table version?
>>
>> Did you look at patch 15?
> 
> Not yet, no (I had looked over the titles, but this one's didn't
> make me make the connection). So yes, that addresses the PV
> DomU concern. Still I'd like to get away without the thin common
> wrapper around the arch specific actual implementation (and I
> don't care much whether the resulting function has an arch_
> prefix).

Okay, I'll remove the common wrapper and drop the arch_ from the x86 and
arm variants.


Juergen

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