Xen devel - Dec 2012 - 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.

On Fri, 2012-12-07 at 17:05 +0000, Konrad Rzeszutek Wilk wrote:
>    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.
I''m not sure I follow -- why does this future change in mainline Linux
have any impact on other kernel trees and their ability to run as dom0?

Ian.

On Mon, Dec 10, 2012 at 09:32:29AM +0000, Ian Campbell
wrote:
> On Fri, 2012-12-07 at 17:05 +0000, Konrad Rzeszutek Wilk wrote:
> 
> >    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.
> 
> I''m not sure I follow -- why does this future change in mainline
Linux
> have any impact on other kernel trees and their ability to run as dom0?
It does not. Thank you for catching that.
The last sentence should not have ''just not as dom0''.
> 
> Ian.
>