Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.08.17 at 13:05, <jgross@xxxxxxxx> wrote:
> On 14/08/17 12:48, Jan Beulich wrote:
>>>>> On 14.08.17 at 12:35, <jgross@xxxxxxxx> wrote:
>>> On 14/08/17 12:29, Jan Beulich wrote:
>>>>>>> On 14.08.17 at 12:21, <jgross@xxxxxxxx> wrote:
>>>>> Current pv guests will only see physical addresses up to 46 bits wide.
>>>>> In order to be able to run on a host supporting 5 level paging and to
>>>>> make use of any possible memory page there, physical addresses with up
>>>>> to 52 bits have to be supported.
>>>>
>>>> Is this a Xen shortcoming or a Linux one (I assume the latter)?
>>>
>>> It is a shortcoming of the Xen pv interface.
>> 
>> Please be more precise: Where in the interface to we have a
>> restriction to 46 bits?
> 
> We have no definition that the mfn width in a pte can be larger than
> the pfn width for a given architecture (in this case a 4 level paging
> 64 bit x86 host).
> 
> So Xen has to assume a guest not telling otherwise has to be limited
> to mfns not exceeding 4 level hosts maximum addresses.

The number of page table levels affects only virtual address
width. Physical addresses can architecturally be 52 bits wide,
and what CPUID extended leaf 8 provides is what limits
physical address width.

> Or would you like to not limit current pv guests to the lower 64TB and
> risk them crashing, just because they interpreted the lack of any
> specific mfn width definition in another way as you do?

Again - you saying "current pv guests" rather than "current
Linux PV guests" makes me assume you've found some
limitation in the PV ABI. Yet so far you didn't point out where
that is, which then again makes me assume you're talking
about a Linux limitation.

>>>>> --- a/xen/include/public/elfnote.h
>>>>> +++ b/xen/include/public/elfnote.h
>>>>> @@ -212,9 +212,18 @@
>>>>>  #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>>>>  
>>>>>  /*
>>>>> + * Maximum physical address size the kernel can handle.
>>>>> + *
>>>>> + * All memory of the PV guest must be allocated below this boundary,
>>>>> + * as the guest kernel can't handle page table entries with MFNs 
>>>>> referring
>>>>> + * to memory above this value.
>>>>> + */
>>>>> +#define XEN_ELFNOTE_MAXPHYS_SIZE 19
>>>>
>>>> Without use in the hypervisor or tools I don't see what good
>>>> introducing this note will do.
>>>
>>> The Linux kernel could make use of it from e.g. kernel 4.14 on. So in
>>> case supports 5 level paging hosts lets say in Xen 4.12 it could run
>>> Linux pv guests with kernel 4.14 making use of high memory addresses.
>>>
>>> In case we don't define the note (or do it rather late) pv guests would
>>> have to be restricted to the low 64TB of host memory.
>> 
>> No matter what you say here - I can't see how defining the note
>> alone will help.
> 
> It will help to introduce the support in Linux for large mfns _now_
> instead of having to wait.

How will that help (other than by knowing the numerical value
for the note)? Once again, without the hypervisor taking any
action upon seeing the note I don't see why on hardware with
wider than 46 bit physical addresses (all(?) AMD CPUs have 48
iirc) the intended effect will be achieved.

> This can be easily compared to the support of 5 level paging in the
> kernel happening right now: When the 5 level paging machines are
> available in the future you won't be limited to a rather recent kernel,
> but you can use one already being part of some distribution.

Yes and no. Since we don't mean to introduce 5-level PV guests,
we're not adding respective MMU ops anyway. If we would, it
would still seem strange to introduced, say, MMUEXT_PIN_L5_TABLE
without also implementing it. But yes, it would be possible, just
that other than here there really would not be a need for the
hypervisor to do anything for it as long as it doesn't itself know
of 5 page table levels.

Jan


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