Re: [XenSummit 2017] Notes from the 5-level-paging session

[Yu Zhang <yu.c.zhang@linux.intel.com>]

On 7/20/2017 6:42 PM, Andrew Cooper wrote:
> On 20/07/17 11:10, Yu Zhang wrote:
>>
>>
>> On 7/17/2017 6:53 PM, Juergen Gross wrote:
>>> Hey,
>>>
>>> I took a few notes at the 5-level-paging session at the summit.
>>> I hope there isn't any major stuff missing...
>>>
>>> Participants (at least naming the active ones): Andrew Cooper,
>>> Jan Beulich, Yu Zhang and myself (the list is just from my memory).
>>>
>>> The following topics have been discussed in the session:
>>>
>>>
>>> 1. Do we need support for 5-level-paging PV guests?
>>>
>>> There is no urgent need for 5-level-paging PV guests for the
>>> following reasons:
>>>
>>> - Guests >64TB (which is the upper limit for 4-level-paging Linux)
>>>    can be PVH or HVM.
>>>
>>> - A 5-level-paging host supports up to 4 PB physical memory. A
>>>    4-level-paging PV-Dom0 can support that theoretically: the M2P map
>>>    for 4 PB memory needs 8 TB space, which just fits into the 
>>> hypervisor
>>>    reserved memory area in the Linux kernel. Any other hypervisor data
>>>    and/or code can live in the additionally available virtual space of
>>>    the 5-level-paging mode.
>>>
>>> There was agreement we don't need support of 5-level-paging PV guests
>>> right now. There is a need, however, to support 4-level-paging PV
>>> guests located anywhere in the 52-bit physical space of a 
>>> 5-level-paging
>>> host (right now they would have to be in the bottom 64 TB as the Linux
>>> kernel is masking away any MFN bit above 64 TB). I will send patches to
>>> support this.
>>>
>>>
>>> 2. Do we need 5-level-paging shadow mode support?
>>>
>>> While strictly required for PV guests only and no 5-level-paging PV
>>> guests are to be supported, we will need 5-level-paging shadow mode in
>>> the long run. This is necessary because even for a 4-level-paging PV
>>> guest (or a 32-bit PV guest) the processor will run in 5-level-paging
>>> mode on a huge host as switching between the paging modes is rather
>>> complicated and should be avoided. It is much easier to run shadow
>>> mode for the whole page table tree instead for two subtrees only.
>>>
>>> OTOH the first step when implementing 5-level-paging in the hypervisor
>>> doesn't require shadow mode to be working, so it can be omitted in the
>>> beginning.
>>>
>>>
>>> 3. Is it possible to support 5-level-paging in Xen via a specific
>>>     binary for the first step?
>>>
>>> Yu Zhang asked for implementing 5-level-paging via a Kconfig option
>>> instead of dynamical switching at boot time for the first prototype.
>>> This request was accepted in order to reduce the complexity of the
>>> initial patches. Boot time switching should be available for the
>>> final solution, though.
>>>
>>>
>>> I hope I didn't miss anything.
>>
>> Thanks a lot for the your help and for the summary, Juergen.
>> And I really need to say thank you for quite a lot people who joined 
>> this discussion. It's quite
>> enlightening. :)
>>
>> One thing I can recall is about the wr{fs,gs}base for pv guest. IIRC, 
>> our agreement is to turn off
>> the FSGSBASE in cr4 for PV guests and try to emulate the 
>> rd{fs,gs}base and wr{fs,gs}base in the
>> #UD handler.
>>
>> But please correct me if I misunderstood. :)
>
> Yes, that matches my understanding.
>
> A second piece of emulation which needs to happen is to modify the #PF 
> handler to notice if a PV guest takes a fault with %cr2 being va57 
> canonical but not va48 canonical.  In this case, we need to decode the 
> instruction as far as working out the segment of the memory operand, 
> and inject #GP[0]/#SS[0] as appropriate.

Thanks, Andrew. So working out the segment is only to decide if #GP or 
#SS is to be injected, right?

And I'm wondering, even when pv guest and hypervisor are both running in 
4 level paging mode,
it could be possible for a #PF to have a va48 canonical address, but 
there's no #GP/#SS injected.
So it is left to the PV guest kernel I guess?

And if the answer is yes, in 5 level case, to whom shall we inject the 
fault? PV guest kernel shall not
handle this fault, right?

B.R.
Yu

> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel


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