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@lists.xen.org
http://lists.xen.org/xen-devel
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@lists.xen.org
http://lists.xen.org/xen-devel