[Fedora-xen] New kernel-xen in rawhide

[Pasi Kärkkäinen]

On Thu, Jul 24, 2008 at 11:37:05AM +0100, Daniel P. Berrange wrote:
> On Thu, Jul 24, 2008 at 01:32:37PM +0300, Pasi K?rkk?inen wrote:
> > On Mon, Jul 21, 2008 at 05:15:41PM +0100, Mark McLoughlin wrote:
> > > On Mon, 2008-07-21 at 14:13 +0100, Mark McLoughlin wrote:
> > > > On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote:
> > > > > On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote:
> > > > > > Hi,
> > > > > > 	Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to
> > > > > > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place
> > > > > > of Eduardo's xen-pvops-64.git tree.
> > > > > > 
> > > > > > 	Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27
> > > > > > already and the other half is queued up, hopefully to be included before
> > > > > > the merge window ends. If we can get that stuff some testing, perhaps it
> > > > > > might help the cause of getting it merged.
> > > > > > 
> > > > > > 	This is all irrelevant if the build fails, of course :-)
> > > > > 
> > > > > Seems to have succeeded, so how about putting it into the real kernel
> > > > > RPM directly, and finally kill kernel-xen as an RPM :-)
> > > > 
> > > > Yes, I'd very much like to make that happen soon.
> > > > 
> > > > There are two considerations, though:
> > > > 
> > > >   1) The second half of the xen x86_64 DomU work has not yet been 
> > > >      merged upstream. It's a fairly big patch:
> > > > 
> > > >        49 files changed, 2344 insertions(+), 913 deletions(-)
> > > > 
> > > >      so, if it doesn't get merged,
> > > 
> > > Sweet, Ingo has just pushed it up to Linus:
> > > 
> > >   http://lkml.org/lkml/2008/7/21/201
> > > 
> > 
> > That's really nice progress with upstream merging..
> > 
> > I still think it might be a good idea to keep separate kernel-xen until
> > upstream has "all" the needed features.. 
> > 
> > Like said, adding dom0 patches should be easier to separate rpm? 
> 
> Possibly - that's TDB when we have working Dom0 patches again. The Dom0
> patches will have to work against latest LKML tree, so it might turn 
> out to be easy to do against the main kernel RPM. It really depends how
> unstable/invasive Dom0 bits are. This is a decision that is independant
> of the guest stuff though.
> 

Ok.

> In terms of guest support, we absolutely want 1 kernel for F10.  A core
> point of paravirt_ops is that a single kernel binary can boot and auto
> detect the hypervisor its running on. This means we can get rid of the
> separate vmlinuz/initrd in the install trees, get rid of anaconda logic
> to install a different kernel in Xen guests, and lots of other cleanup.
> 

That makes sense. 

Thanks.

-- Pasi