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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.
~Andrew

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