[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [XenSummit 2017] Notes from the 5-level-paging session
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 mapfor 4 PB memory needs 8 TB space, which just fits into the hypervisorreserved 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 PVguests located anywhere in the 52-bit physical space of a 5-level-paginghost (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 quiteenlightening. :)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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |