Xen dom0 Kernel Patches

Xen dom0 Kernel Patches

[Andrew Lyon]

The recent discussions about pv_ops dom0 has left me in some doubt
about using Xen in a production environment, while various distros
forward port the Xen patches only openSUSE does so for very recent
kernels like 2.6.29, I regularly grab the kernel source rpm from them,
rebase the patches to apply to vanilla, and release a Gentoo ebuild
which quite a few people have used successfully, but I doubt I am
alone in wanting a official dom0 kernel that is not years old.

My question is this, given that the openSUSE patches seem to work
quite well would it really be so much work to at least update the
Xensource kernel to 2.6.29 or .30? I believe openSUSE use a semi
automated process for forward porting but however they do it the
results are quite good, couldn't the Xen developers work with the
distro maintainers to keep the patches up to date? I understand that
each distro has its own set of additional kernel patches but if the
work was done on Vanilla then they could all apply the Xen patches
first and adjust their other patches as necessary.

It seems to me that a huge amount of effort is being duplicated in the
forward porting when a combined effort is bound to produce better
results, if multiple distro's can find the resources to do it surely
working together with Xensource would be less effort for everybody.

The openSUSE patches I have used are from the bleeding edge kernel
builds and 2.6.29 is no longer available, but my current patchset
applies to Vanilla 2.6.29 and can be downloaded from
http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2,
the Xensource maintainers could grab that as a starting point and help
to fix any bugs that remain.

I understand that the kernel is a moving target and 2.6.29 will soon
be out of date, but I don't think that justifies simply not providing
a newer one because pv_ops will be in mainline "any time soon", it
really feel that it is going to take a long time before that happens,
if at all.

Andy

Re: Xen dom0 Kernel Patches

[Pasi Kärkkäinen]

On Wed, Jun 03, 2009 at 07:49:17PM +0100, Andrew Lyon wrote:
> The recent discussions about pv_ops dom0 has left me in some doubt
> about using Xen in a production environment, while various distros
> forward port the Xen patches only openSUSE does so for very recent
> kernels like 2.6.29, I regularly grab the kernel source rpm from them,
> rebase the patches to apply to vanilla, and release a Gentoo ebuild
> which quite a few people have used successfully, but I doubt I am
> alone in wanting a official dom0 kernel that is not years old.
> 
> My question is this, given that the openSUSE patches seem to work
> quite well would it really be so much work to at least update the
> Xensource kernel to 2.6.29 or .30? I believe openSUSE use a semi
> automated process for forward porting but however they do it the
> results are quite good, couldn't the Xen developers work with the
> distro maintainers to keep the patches up to date? I understand that
> each distro has its own set of additional kernel patches but if the
> work was done on Vanilla then they could all apply the Xen patches
> first and adjust their other patches as necessary.
> 
> It seems to me that a huge amount of effort is being duplicated in the
> forward porting when a combined effort is bound to produce better
> results, if multiple distro's can find the resources to do it surely
> working together with Xensource would be less effort for everybody.
> 
> The openSUSE patches I have used are from the bleeding edge kernel
> builds and 2.6.29 is no longer available, but my current patchset
> applies to Vanilla 2.6.29 and can be downloaded from
> http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2,
> the Xensource maintainers could grab that as a starting point and help
> to fix any bugs that remain.
> 

Good work with the patches.

Are you willing to maintain such patchsets? The temporary 2.6.27-xen tree made for
Novell/SuSE guys is totally unmaintained.. 

I think most of the development effort should be used on getting pv_ops dom0 ready for
mainline, but if you (for example), want to maintain forward-ported patches
for new kernel versions, it sounds like a good idea.. for the time being.

-- Pasi

Re: Xen dom0 Kernel Patches

[Andrew Lyon]

On Wed, Jun 3, 2009 at 8:35 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Wed, Jun 03, 2009 at 07:49:17PM +0100, Andrew Lyon wrote:
>> The recent discussions about pv_ops dom0 has left me in some doubt
>> about using Xen in a production environment, while various distros
>> forward port the Xen patches only openSUSE does so for very recent
>> kernels like 2.6.29, I regularly grab the kernel source rpm from them,
>> rebase the patches to apply to vanilla, and release a Gentoo ebuild
>> which quite a few people have used successfully, but I doubt I am
>> alone in wanting a official dom0 kernel that is not years old.
>>
>> My question is this, given that the openSUSE patches seem to work
>> quite well would it really be so much work to at least update the
>> Xensource kernel to 2.6.29 or .30? I believe openSUSE use a semi
>> automated process for forward porting but however they do it the
>> results are quite good, couldn't the Xen developers work with the
>> distro maintainers to keep the patches up to date? I understand that
>> each distro has its own set of additional kernel patches but if the
>> work was done on Vanilla then they could all apply the Xen patches
>> first and adjust their other patches as necessary.
>>
>> It seems to me that a huge amount of effort is being duplicated in the
>> forward porting when a combined effort is bound to produce better
>> results, if multiple distro's can find the resources to do it surely
>> working together with Xensource would be less effort for everybody.
>>
>> The openSUSE patches I have used are from the bleeding edge kernel
>> builds and 2.6.29 is no longer available, but my current patchset
>> applies to Vanilla 2.6.29 and can be downloaded from
>> http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2,
>> the Xensource maintainers could grab that as a starting point and help
>> to fix any bugs that remain.
>>
>
> Good work with the patches.

Its really nothing, I am by no means a experienced C programmer, I
just have enough knowledge to figure out how to fix the few rejected
hunks in the patches, and I've fixed a couple of small bugs where
datatypes were mismatched, but I've also had crash reports from users
which I was unable to help with :(, if a couple of more knowledgeable
people who could help with the tricky problems I think we could
maintain a decent standard of reliability.

>
> Are you willing to maintain such patchsets? The temporary 2.6.27-xen tree made for
> Novell/SuSE guys is totally unmaintained..

Depends what you mean by maintain, I'm willing to try to update the
2.6.29 patches as minor kernel versions are released, and with any
bugfixes that are commited to
http://xenbits.xensource.com/linux-2.6.18-xen.hg, and I think even the
current state of my 2.6.29 is better than the 2.6.27-xen tree, and
when 2.6.30 is released I will rebase the openSUSE patches again, what
makes it difficult is that I've no idea how openSUSE make the patches
in the first place, I am fairly sure it is not fully automated so
there may be a commits mailing list where I could learn more about
where the patches are derived from. They are bleeding edge kernels and
openSUSE soon abandon the stable release and switch to the latest
-git, so once a new stable kernel is released my source of updated
patches dries up.

The second issue is that sometimes I have very little free time, it
completely depends on my workload in my paying job ;).

>
> I think most of the development effort should be used on getting pv_ops dom0 ready for
> mainline, but if you (for example), want to maintain forward-ported patches
> for new kernel versions, it sounds like a good idea.. for the time being.

I totally agree, but I've got a virtualization project which is
starting soon and I want to use Xen for it, but even if it runs
smoothly with my kernel I still worry about using a self maintained
kernel, the Xensource one lacks some hardware support which we
require, and none of the distro supported kernels are new enough.

Perhaps I should contact the people who forward port for other distros...

Andy

RE: Xen dom0 Kernel Patches

[Ian Pratt]

> Are you willing to maintain such patchsets? The temporary 2.6.27-xen tree
> made for Novell/SuSE guys is totally unmaintained..

The 2.6.27 git tree and patchqueue under the Xen Client Initiative directory on xenbits is fairly well maintained: http://xenbits.xen.org/XCI/
 
To my mind this would be a better default tree for us to use for xen-unstable than the ancient 2.6.18. We obviously want to continue to encourage folk to try Jeremy's pvops dom0 stable tree based off the latest linux release too. 

Ian

 
> I think most of the development effort should be used on getting pv_ops
> dom0 ready for
> mainline, but if you (for example), want to maintain forward-ported patches
> for new kernel versions, it sounds like a good idea.. for the time being.
> 
> -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Xen dom0 Kernel Patches

[Gerd Hoffmann]

   Hi,

> My question is this, given that the openSUSE patches seem to work
> quite well would it really be so much work to at least update the
> Xensource kernel to 2.6.29 or .30? I believe openSUSE use a semi
> automated process for forward porting but however they do it the
> results are quite good,

Jan Beulich does it.  I doubt it is automated process.  There are tools 
like quilt though which help maintaining and rebasing patch queues.  Now 
with the x86 merge being mostly done rebasing the patches to a newer 
kernel is probably easier again.

> It seems to me that a huge amount of effort is being duplicated in the
> forward porting when a combined effort is bound to produce better
> results, if multiple distro's can find the resources to do it surely
> working together with Xensource would be less effort for everybody.

There is no duplicated effort.  Everybody with xen patches against 
recent kernels just uses the opensuse patches.

> I understand that the kernel is a moving target and 2.6.29 will soon
> be out of date, but I don't think that justifies simply not providing
> a newer one because pv_ops will be in mainline "any time soon", it
> really feel that it is going to take a long time before that happens,
> if at all.

Even with the bits not being merged into mainline you can still pull 
jeremies git tree to get a pv_ops based kernel with dom0 support.

cheers,
   Gerd

Re: Xen dom0 Kernel Patches

[Keir Fraser]

On 03/06/2009 22:24, "Gerd Hoffmann" <kraxel@redhat.com> wrote:

>> I understand that the kernel is a moving target and 2.6.29 will soon
>> be out of date, but I don't think that justifies simply not providing
>> a newer one because pv_ops will be in mainline "any time soon", it
>> really feel that it is going to take a long time before that happens,
>> if at all.
> 
> Even with the bits not being merged into mainline you can still pull
> jeremies git tree to get a pv_ops based kernel with dom0 support.

Yes, it doesn't have to be all pushed upstream for it to be used. It's just
a question of how big the out-of-upstream patchset is that Jeremy has to
manage. And actually there's maintenance work even with the upstreamed
patches, of course. But none of that directly matters for consumers of
Jeremy's tree.

 -- Keir

Re: Xen dom0 Kernel Patches

[Tim Post]

On Wed, 2009-06-03 at 22:31 +0100, Keir Fraser wrote:

> Yes, it doesn't have to be all pushed upstream for it to be used. It's just
> a question of how big the out-of-upstream patchset is that Jeremy has to
> manage. And actually there's maintenance work even with the upstreamed
> patches, of course. But none of that directly matters for consumers of
> Jeremy's tree.

No, of course it doesn't. The problem is, Jeremy's tree is very much a
moving target as he works to produce patches that upstream will accept.

I think what most people really want is something to use in the mean
time which remains relatively static (but maintained, i.e. CVE's,
bugfixes, etc). If several distros and the community at large pulled
from a common repository, the result would be a very stable kernel (even
if not good enough for submission upstream).

What ends up happening is Linux maintenance falls on the backs of the
integrators who promote and sell solutions based on Xen. Its not that
this situation is in any way _unfair_, we're making money because of
Xen. Rather, in most cases, its _untenable_ unless the integrator has in
depth kernel knowledge.

Its a frustrating situation, 10,000+ people would be willing to help, if
only their aptitudes matched the problem at hand.

Cheers,
--Tim

Re: Xen dom0 Kernel Patches

[Gerd Hoffmann]

On 06/04/09 05:43, Tim Post wrote:
> On Wed, 2009-06-03 at 22:31 +0100, Keir Fraser wrote:
>
>> Yes, it doesn't have to be all pushed upstream for it to be used. It's just
>> a question of how big the out-of-upstream patchset is that Jeremy has to
>> manage. And actually there's maintenance work even with the upstreamed
>> patches, of course. But none of that directly matters for consumers of
>> Jeremy's tree.
>
> No, of course it doesn't. The problem is, Jeremy's tree is very much a
> moving target as he works to produce patches that upstream will accept.

Well, that might be fixable without too much effort.  Maybe jeremy could 
simply branch off a stable branch for 2.6.30 before rebasing to 
2.6.31-rc1?  Just to have something people can pull which is not based 
on some -rc bleeding edge kernel?  That branch wouldn't get updates, 
except maybe for cherry-picked bugfixes, maybe also 2.6.30.x stable 
patches if they apply cleanly.  Development would still happen in the 
xen-next + xen-master branches of course.

cheers,
   Gerd

Re: Xen dom0 Kernel Patches

[Tim Post]

On Thu, 2009-06-04 at 08:59 +0200, Gerd Hoffmann wrote:
> On 06/04/09 05:43, Tim Post wrote:
> > On Wed, 2009-06-03 at 22:31 +0100, Keir Fraser wrote:
> >
> >> Yes, it doesn't have to be all pushed upstream for it to be used. It's just
> >> a question of how big the out-of-upstream patchset is that Jeremy has to
> >> manage. And actually there's maintenance work even with the upstreamed
> >> patches, of course. But none of that directly matters for consumers of
> >> Jeremy's tree.
> >
> > No, of course it doesn't. The problem is, Jeremy's tree is very much a
> > moving target as he works to produce patches that upstream will accept.
> 
> Well, that might be fixable without too much effort.  Maybe jeremy could 
> simply branch off a stable branch for 2.6.30 before rebasing to 
> 2.6.31-rc1?

Even semi-stable would be agreeable as a start. If the various distros
and users who want to package Xen focus their efforts on that single
repository, it 'semi' could be dropped very quickly.

>   Just to have something people can pull which is not based 
> on some -rc bleeding edge kernel?  That branch wouldn't get updates, 
> except maybe for cherry-picked bugfixes, maybe also 2.6.30.x stable 
> patches if they apply cleanly.

That's what I was proposing. Just CVE's and major bugfixes would do just
fine. If people want fixups in a file system, they can just cherry pick
on their own. The idea being customers of that repo only need to update
their deployments when something really scary or really juicy is pulled.

An example of juicy: the stuff Dan is working on. There's no reason why
new experimental features can't go into the static tree, that keeps them
from cluttering Jeremy's workspace while getting them attention and
testing.

> Development would still happen in the 
> xen-next + xen-master branches of course.

Yes. If -stable can keep up with (or one version behind) mainline, the
whole sense of urgency to see everything merged goes down to a dull
roar.

Its not just users, integrators and developers who have been watching
these lists for the last few weeks .. its also our customers.

Cheers,
--Tim

RE: Xen dom0 Kernel Patches

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1818 bytes --]

Through my experience xenified kernel been built on 
   # hg clone http://xenbits.xensource.com/ext/linux-2.6.27-xen.hg
works  fine under Xen 3.3.1,3.4,3.5-unstable.
However, attempt to shutdown Xen Host causes dropping into stack trace.
Kernel 2.6.29.4 with rebased patches suggested by Andy Lyon allows to
shutdown Xen Host cleanly.

Boris.

--- On Thu, 6/4/09, Ian Pratt <Ian.Pratt@eu.citrix.com> wrote:

From: Ian Pratt <Ian.Pratt@eu.citrix.com>
Subject: RE: [Xen-devel] Xen dom0 Kernel Patches
To: "Pasi Kärkkäinen" <pasik@iki.fi>, "Andrew Lyon" <andrew.lyon@gmail.com>
Cc: "Ian Pratt" <Ian.Pratt@eu.citrix.com>, "Xen-devel" <xen-devel@lists.xensource.com>
Date: Thursday, June 4, 2009, 11:08 AM

> Are you willing to maintain such patchsets? The temporary 2.6.27-xen tree
> made for Novell/SuSE guys is totally unmaintained..

The 2.6.27 git tree and patchqueue under the Xen Client Initiative directory on xenbits is fairly well maintained: http://xenbits.xen.org/XCI/
 
To my mind this would be a better default tree for us to use for xen-unstable than the ancient 2.6.18. We obviously want to continue to encourage folk to try Jeremy's pvops dom0 stable tree based off the latest linux release too. 

Ian

 
> I think most of the development effort should be used on getting pv_ops
> dom0 ready for
> mainline, but if you (for example), want to maintain forward-ported patches
> for new kernel versions, it sounds like a good idea.. for the time being.
> 
> -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2675 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Xen dom0 Kernel Patches

[Pasi Kärkkäinen]

On Thu, Jun 04, 2009 at 10:55:44AM -0700, Boris Derzhavets wrote:
> Through my experience xenified kernel been built on 
>    # hg clone http://xenbits.xensource.com/ext/linux-2.6.27-xen.hg
> works  fine under Xen 3.3.1,3.4,3.5-unstable.
> However, attempt to shutdown Xen Host causes dropping into stack trace.
> Kernel 2.6.29.4 with rebased patches suggested by Andy Lyon allows to
> shutdown Xen Host cleanly.
> 

Ian proposed the _other_ 2.6.27-xen tree from XCI project:
http://xenbits.xen.org/XCI/

-- Pasi

> Boris.
> 
> --- On Thu, 6/4/09, Ian Pratt <Ian.Pratt@eu.citrix.com> wrote:
> 
> From: Ian Pratt <Ian.Pratt@eu.citrix.com>
> Subject: RE: [Xen-devel] Xen dom0 Kernel Patches
> To: "Pasi Kärkkäinen" <pasik@iki.fi>, "Andrew Lyon" <andrew.lyon@gmail.com>
> Cc: "Ian Pratt" <Ian.Pratt@eu.citrix.com>, "Xen-devel" <xen-devel@lists.xensource.com>
> Date: Thursday, June 4, 2009, 11:08 AM
> 
> > Are you willing to maintain such patchsets? The temporary 2.6.27-xen tree
> > made for Novell/SuSE guys is totally unmaintained..
> 
> The 2.6.27 git tree and patchqueue under the Xen Client Initiative directory on xenbits is fairly well maintained: http://xenbits.xen.org/XCI/
>  
> To my mind this would be a better default tree for us to use for xen-unstable than the ancient 2.6.18. We obviously want to continue to encourage folk to try Jeremy's pvops dom0 stable tree based off the latest linux release too. 
> 
> Ian
> 
>  
> > I think most of the development effort should be used on getting pv_ops
> > dom0 ready for
> > mainline, but if you (for example), want to maintain forward-ported patches
> > for new kernel versions, it sounds like a good idea.. for the time being.
> > 
> > -- Pasi
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 
>