In the spirit of improving communication of Fedora Xen plans to the world,
below is a mail I recently circulated in the Fedora community about the
direction for Xen-ified kernels from Fedora 9 and onwards.
The short story, is that we intend to ship hypervisor & userspace based on
Xen 3.2.0 tree, and a kernel based on latest LKML pv_ops tree and patches
ontop of that to support Dom0 and x86_64. With some short term pain and
instability, we hope to get significant long term benefits for support of
Xen Linux kernels.
The long story is the mail below..
We have a number of kernel guys working on this project, and Stephen will
shortly followup with details of his current patch queue, for benefit of
anyone else who wishes to track this / get involved.
Regards,
Dan.
----- Forwarded message from "Daniel P. Berrange" <berrange@xxxxxxxxxx> -----
> Date: Fri, 30 Nov 2007 18:59:09 +0000
> From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
> To: fedora-xen@xxxxxxxxxx
> Subject: FYI: The plan for Xen kernels in Fedora 9
>
> This is a friendly alert of the major plans we have for Xen kernels in
> Fedora 9 timeframe...
>
> Since we first added Xen in Fedora Core 5, our kernels have been based on
> a forward-port of XenSource's upstream Xen kernels, to new LKML. For a
> long time we ported their 2.6.16 tree to 2.6.18. Now we do ports of their
> 2.6.18 tree to 2.6.21/22/23, etc. At the same time, upstream Linux gained
> Xen support for i386 DomU, and shortly x86_64 DomU, and is generally
> getting ever more virtualization capabilities.
>
> As everyone knows, we have tended to lag behind Fedora's state-of-the-art
> bare metal kernels by several releases due to the effort required to port
> Xen to newer LKML releases. Despite our best efforts, this lag has been
> getting worse, not better.
>
> We have taken the decision, that this situation is unacceptable for Fedora 9.
> We simply cannot spend more time forward porting Xen kernels. Either Xen has
> to be dropped entirely, or we need a different strategy for dealing with the
> kernels. Since people seeem to use Xen, we have decided not to drop it :-)
>
> So the plan is to re-focus 100% of all Xen kernel efforts onto paravirt_ops.
> LKML already has i386 pv_ops + Xen DomU. We intend to build on this to
> add:
>
> - x64_64 pv_ops
> - x86_64 Xen DomU on pv_ops
> - i386 & x86_64 Xen Dom0 on pv_ops
> - memory balloon
> - paravirt framebuffer
> - save/restore
>
> All of this based on same LKML release as Fedora bare metal. If all goes to
> plan it may even be in the base kernel RPM, instead of kernel-xen, but thats
> a minor concern compared to the actual coding.
>
> Getting all this done for Fedora 9 is seriously ambitious, but it is the only
> long term sustainable option, other than dropping Xen entirely.
>
> What this means though, is that Fedora 9 Xen will certainly be going through
> periods of instability and will certainly be even buggier than normal. F9
> may well end up lacking features compared to Xen in Fedora 8 & earlier (eg no
> PCI device passthrough, or CPU hotplug). On the plus side though we will be
> 100% back in sync with bare metal kernel versions & hopefully even have a
> lot of this stuff merged in LKML to make ongoing maintainence sustainable.
> Short term pain; Long term gain!
>
> I have not got any ETA on when any of these kernel changes will appear in
> rawhide - some time before the F9 feature freeze date is best guesstimate.
> We will alert people when the time comes. There is a F9 feature page
> with some amount of info about the plan...
>
> http://fedoraproject.org/wiki/Features/XenPvops
>
> In terms of Fedora 6/7/8 maintainence... The kernel-xen in these existing
> releases already lags behind the bare metal kernel version by 2-3 releases.
> We do not intend to continue trying to rebase the kernel-xen in existing
> Fedora releases. It will be essentially important bug-fix mode only. This
> is neccessary to enable maximum resources to be focused on the critical
> Fedora 9 Xen work.
>
> Regards,
> Dan ...on behalf of some very busy Fedora Xen kernel developers :-)
> --
> |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
> |=- Perl modules: http://search.cpan.org/~danberr/ -=|
> |=- Projects: http://freshmeat.net/~danielpb/ -=|
> |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
>
----- End forwarded message -----
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|