From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Subject: Re: SOLVED: Re: Issue with pv_ops Kernel 2.6.31.6 and Xen [yinghai@kernel.org: [PATCH 01/35] x86: fix sci on ioapic 1] Date: Wed, 17 Feb 2010 21:20:28 +0200 Message-ID: <20100217192028.GI2861@reaktio.net> References: <4B7C3AF8.2070000@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Michael D Labriola Cc: Marcial Rion , Jeremy Fitzhardinge , xen-devel@lists.xensource.com, xen-devel-bounces@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Wed, Feb 17, 2010 at 02:07:03PM -0500, Michael D Labriola wrote: > xen-devel-bounces@lists.xensource.com wrote on 02/17/2010 01:52:40 PM: >=20 > > On 02/17/2010 12:33 AM, Pasi K=E4rkk=E4inen wrote: > > > On Tue, Feb 16, 2010 at 01:51:05PM -0800, Jeremy Fitzhardinge wrote= : > > >=20 > > >>> > > >>>=20 > > >>>> Question: Is it known when this piece of code will be introduced= in=20 > the > > >>>> "pv_ops Kernel tree"? > > >>>> > > >>>>=20 > > >>> Hmm.. Jeremy's plans are to re-base the pvops changes that went i= n > > >>> 2.6.31.6 onto 2.6.32. The reason being that 2.6.32 has been choos= en=20 > by > > >>> many distributions as their next vehicle for release. The patches= =20 > being > > >>> mostly, if possible, related only to Xen. > > >>> > > >>> The patch I forwarded to you is targetted for 2.6.33 so it wouldn= ot=20 > appear > > >>> normally in 2.6.32 tree unles Greg KH choose to back-port it in.=20 > Greg is > > >>> the maintainer of the 2.6.32 stable tree. > > >>> > > >>> I would recommend you e-mail Greg KH with this e-mail, explain yo= ur > > >>> situation and ask him if he wouldn't mind merging the patch in. > > >>> Thought you might need to do some of the work yourself > > >>> (as in, merge the patch in an earlier kernel) - it seems you alre= ady > > >>> have done this so hopefully that shouldn't be a problem. > > >>> > > >>> Try it that way, as this way also the distributions will pick up = the=20 > fix > > >>> and you would be able to load any new distro on your box without=20 > having > > >>> to manually recompile the kernel and such. > > >>> > > >>>=20 > > >> Is that one change enough to fix the reported problem? Can we jus= t > > >> cherry-pick it over? Or does it need a lot of supporting patches? > > >> > > >>=20 > > >>> Then when Jeremy revs up the xen/next tree to next stable rev (I=20 > think > > >>> he will do this, not sure?), it will automatically be picked up=20 > > (if Greg picks it up in his tree). > > >>> > > >>>=20 > > >> Yes. At the moment xen/next is based on plain 2.6.32 because that= is > > >> also an ancestor version of mainline git development. Once the=20 > 2.6.32 > > >> tree basically works (which should be close), then I can merge all= =20 > the > > >> stable branch changes onto it and call it "xen/stable" or somethin= g. > > >> > > >>=20 > > > So that means I should try xen/next now? :) > > >=20 > >=20 > > Give it a go. It boots OK for me, and I can start xend. But I get=20 > > domains hanging in pvgrub; I'm not sure blkback is working properly. = Or=20 >=20 > > it could be a tools issue... >=20 > Does this require Xen 4.0-rc or can I do some testing using my 3.4.2=20 > installs? >=20 I believe xen/next uses the new APIC setup stuff, so it requires Xen 4.0.= 0 hypervisor. Correct?=20 iirc earlier there was a patch on xen-devel to support the new APIC stuff= with Xen 3.4 hypervisor. Was it this patch?: http://xenbits.xen.org/xen-3.4-testing.hg?rev/608ebc959c35 -- Pasi