[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Linux Kernel Summit 2012 hallway talks - PV MMU, PVH, hpa, tglrx, stefano and me.
This year during the Linux Kernel Summit in the hallways we were discussing the paravirt and PV MMU interface with tglrx and hpa. The x86 maintainers would like to rewrite parts of the MMU code (specifically the page table creation/tear down) and are hitting the wall of not knowing whether changing some of the paravirt calls will have an adverse effect on Xen. We hit that in the past with something seemingly innocent - but it caused us quite the headache. Look in git commit 279b706bf800b5967037f492dbe4fc5081ad5d0f (x86,xen: introduce x86_init.mapping.pagetable_reserve) for details. Peter (hpa) explained a nice and quite neat mechanism to the pagetable creation after tglrx and hpa looked at how unwieldy the pagetable creation is nowadays (arch/x86/mm/*). This is nicely explained in https://lkml.org/lkml/2012/10/4/701 The patches for this have been written by Jinghai and are on the queue for v3.8. They will eliminate the above mentioned hook (pagetable_reserve). We also explained how the PVH mode that Mukesh is working on will benefit re-write of the MMU code as it would not have to worry about Xen's PV MMU rules. We got in more details about what else we would like to do and it came down to: - Continue removing pvops function calls we don't use. There are some that have the same exact functions for both Xen, lguest and baremetal. I am on the hook to do an audit of this but hadn't gotten very far. - Wait until the PVH patches have been posted and are in a good stage. For those that don't know what PVH is, this blog has a very good explanation of it and is worth the read: http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/ I would highly recommend reading it - it also has a bit of history and explanation of the different modes. Anyhow, once the PVH works - so can do SMP guests, does properly interrupt delivery, etc, we would obsolete the PV MMU mode in 5 years. This means that arch/x86/xen/p2m.c and arch/x86/xen/mmu.c along with a host of paravirt interfaces would be #ifdef-ed out. There would also be a note in the Documentation/deprecate-schedule pointing that out. If everything time-wise aligns itself that means 2013 is when PVH has it debut and will have its kinks worked out. 2018 is when PV MMU would be obsoleted. The impact is that in 2018 users would need Intel VT-d or AMD VI-IOMMU capable machine to run the latest Linux dom0 kernel with device drivers on x86. You would still be able to run the ancient PV kernels (like 2.6.18) as guests - just not as a dom0. The hypervisor would still support the hypercalls - so in 2018 you could still run with Xen X.Y with a pre-2018 mainline kernel. The reasoning behind this move is: - faster performance. The PVH which uses the hardware VMX container and VT-d allows us to run PV guests faster. Look in details at Mukesh's presentation at this year XenSummit: http://vimeo.com/album/2068760/video/49506288 - Less code to maintain = less chance of bugs. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |