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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel