Replacing the current forward-ported XenSource code in kernel-xen with the paravirt_ops based implementation from upstream. DomU support only, for now.

Replacing the current forward-ported XenSource code in kernel-xen with the paravirt_ops based implementation from upstream. DomU support only, for now.

−

Dom0 support is targetted to [[Releases/10| Fedora 10]] and being tracked on [[Features/XenPvopsDom0]] .

+

Xen pv_ops Dom0 support is being tracked on [[Features/XenPvopsDom0]] .

+

+

Xen pv_ops domU support is now included in the vanilla/mainline Linux kernel, for x86_32, x86_64 and ia64, so separate kernel-xen package is dropped, and it is not anymore present in Fedora 10. Xen domU support is included in the normal kernel rpm. In Fedora 11, the kernel-PAE package is required for pv_ops support.

Xen pv_ops domU support is now included in the vanilla/mainline Linux kernel, for x86_32, x86_64 and ia64, so separate kernel-xen package is dropped, and it is not anymore present in Fedora 10. Xen domU support is included in the normal kernel rpm. In Fedora 11, the kernel-PAE package is required for pv_ops support.

Currently, the Fedora kernel-xen package is based on forward-porting of the XenSource patches from 2.6.18 to more recent kernel versions. This has many problems, including:

XenSource code has no chance of being merged upstream, in the near future, making the forward-porting work needed for all new kernel versions.

Lots of porting work for each new kernel version

Because of the above, kernel-xen has been some releases behind the non-xen kernel package, and the lag between kernel and kernel-xen has been increasing constantly.

As of November 2007, the kernel-xen forward-porting was being finished for 2.6.22, and Linux 2.6.24 was about to be released. The effort needed for 2.6.23, 2.6.24 and later would have been even bigger with the introduction of paravirt_ops and the i386-x86_64 merge upstream. Thus, the decision was made to abandon the forward-porting effort and focus on upstream paravirt_ops.

This whole feature is pretty high risk - it involves lots of scary work against the kernel. Already mitigating against some risk by continuing to target a separate kernel-xen RPM to minimize risk to the baremetal builds. There are several backup plans ...

This is a very likely scenario. Dom0 is not likely to be complete enough to risk adding as a patch to regular bare-metal in time for GA, so will keep as a separate RPM initially, cleaning up patch for F10