[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [FW: FYI: The plan for Xen kernels in Fedora 9]



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.