Future of xenbits Linux trees

Future of xenbits Linux trees

[Keir Fraser]

Folks,

With 3.4 out the door it is time to revisit the state of our Linux
repositories. Currently we have a number of trees in various states of
maintenance:
 - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
tested but increasingly long in the tooth.
 - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
clones tree is not maintained or tested.
 - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
Maintained as part of XCI project.
 - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
tested, but incomplete.

It is probably time to kill the 2.6.18 tree, or at least stop active
development within it. It is increasingly a kludged collection of backports
of more recent kernel patches, and is also missing a lot of drivers for more
modern hardware.

Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
and make it the main user tree. Development and automated testing would
occur on that tree and of course on Jeremy's pv_ops patchset (which we want
to completely move onto at some point in the future).

What do people think of this as a plan?

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>

This tree is not tied up with XCI at all.
It can be taken as it and runs on the top of mainstream xen.

Jean

Re: Future of xenbits Linux trees

[Tim Post]

On Thu, 2009-06-04 at 16:45 +0100, Keir Fraser wrote:

> What do people think of this as a plan?

Just tell me where to send the beer.

Cheers,
--Tim

Re: Future of xenbits Linux trees

[Espen Skoglund]

Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.

One question: How complete is the XCI tree with respect to the various
Xen related features having been added to the 2.6.18 tree over time?
Is it all in there?

	eSk



[Keir Fraser]
> Folks,
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.

> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of
> backports of more recent kernel patches, and is also missing a lot
> of drivers for more modern hardware.

> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI
> subproject and make it the main user tree. Development and automated
> testing would occur on that tree and of course on Jeremy's pv_ops
> patchset (which we want to completely move onto at some point in the
> future).

> What do people think of this as a plan?

>  -- Keir



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

Re: Future of xenbits Linux trees

[Keir Fraser]

On 04/06/2009 19:08, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:

> Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.
> 
> One question: How complete is the XCI tree with respect to the various
> Xen related features having been added to the 2.6.18 tree over time?
> Is it all in there?

There may be pieces missing relating to power management and device
passthrough. They can be added down the line however, and the 2.6.18 tree
won't be deleted.

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> On 04/06/2009 19:08, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:
>
>> Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.
>>
>> One question: How complete is the XCI tree with respect to the various
>> Xen related features having been added to the 2.6.18 tree over time?
>> Is it all in there?
>
> There may be pieces missing relating to power management and device
> passthrough. They can be added down the line however, and the 2.6.18 tree
> won't be deleted.
>


We have pciback with flr,blktap2 in term of new things.

Jean

Re: Future of xenbits Linux trees

[Andrew Lyon]

On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>
>  -- Keir

I think 2.6.27 is already out of date and you should start with 2.6.29
using my rebased patches, people have been using them since I did
2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
does, I'm sure that could be fixed but right now I dont know of any
issues with 2.6.29 at all, so why not make the jump to the current
stable kernel :).

XCI should update to 2.6.29 as well.

I use pci passthrough with a pci express usb2 card, I also use scsi
passthrough with a ultrium tape drive, usually running several windows
hvm's and a couple of 2.6.29 pv domU's as well, no problems.

Andy

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 08:32:21AM +0100, Andrew Lyon wrote:
> On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> > Folks,
> >
> > With 3.4 out the door it is time to revisit the state of our Linux
> > repositories. Currently we have a number of trees in various states of
> > maintenance:
> >  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> > tested but increasingly long in the tooth.
> >  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> > clones tree is not maintained or tested.
> >  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> > Maintained as part of XCI project.
> >  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> > tested, but incomplete.
> >
> > It is probably time to kill the 2.6.18 tree, or at least stop active
> > development within it. It is increasingly a kludged collection of backports
> > of more recent kernel patches, and is also missing a lot of drivers for more
> > modern hardware.
> >
> > Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> > and make it the main user tree. Development and automated testing would
> > occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> > to completely move onto at some point in the future).
> >
> > What do people think of this as a plan?
> >
> >  -- Keir
> 
> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
> 
> XCI should update to 2.6.29 as well.
> 

Just to clear it up, Keir proposed to use the XCI 2.6.27-git tree as a
starting point, not the unmaintained and buggy 2.6.27-xen.

But anyway, I think the best option would be to start with Andrew's patches
for 2.6.29.

> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.
> 

That's good.

-- Pasi

Re: Future of xenbits Linux trees

[Keir Fraser]

On 05/06/2009 08:32, "Andrew Lyon" <andrew.lyon@gmail.com> wrote:

> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
> 
> XCI should update to 2.6.29 as well.
> 
> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.

That's certainly an option, especially if it has stuff like pciback,
blktap2, and various patches for device passthrough (e.g., using VT-d)
already ported to it, similar to the XCI 2.6.27 tree.

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
>> Folks,
>>
>> With 3.4 out the door it is time to revisit the state of our Linux
>> repositories. Currently we have a number of trees in various states of
>> maintenance:
>>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
>> tested but increasingly long in the tooth.
>>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
>> clones tree is not maintained or tested.
>>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
>> Maintained as part of XCI project.
>>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
>> tested, but incomplete.
>>
>> It is probably time to kill the 2.6.18 tree, or at least stop active
>> development within it. It is increasingly a kludged collection of backports
>> of more recent kernel patches, and is also missing a lot of drivers for more
>> modern hardware.
>>
>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>> and make it the main user tree. Development and automated testing would
>> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
>> to completely move onto at some point in the future).
>>
>> What do people think of this as a plan?
>>
>>  -- Keir
>
> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
>
> XCI should update to 2.6.29 as well.
>
> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.
>

Hi Andy,

Where could I get this 2.6.29 from?

Thanks,
Jean

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 08:58:01AM +0100, Jean Guyader wrote:
> 2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> > On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> >> Folks,
> >>
> >> With 3.4 out the door it is time to revisit the state of our Linux
> >> repositories. Currently we have a number of trees in various states of
> >> maintenance:
> >>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> >> tested but increasingly long in the tooth.
> >>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> >> clones tree is not maintained or tested.
> >>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> >> Maintained as part of XCI project.
> >>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> >> tested, but incomplete.
> >>
> >> It is probably time to kill the 2.6.18 tree, or at least stop active
> >> development within it. It is increasingly a kludged collection of backports
> >> of more recent kernel patches, and is also missing a lot of drivers for more
> >> modern hardware.
> >>
> >> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> >> and make it the main user tree. Development and automated testing would
> >> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> >> to completely move onto at some point in the future).
> >>
> >> What do people think of this as a plan?
> >>
> >>  -- Keir
> >
> > I think 2.6.27 is already out of date and you should start with 2.6.29
> > using my rebased patches, people have been using them since I did
> > 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> > thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> > does, I'm sure that could be fixed but right now I dont know of any
> > issues with 2.6.29 at all, so why not make the jump to the current
> > stable kernel :).
> >
> > XCI should update to 2.6.29 as well.
> >
> > I use pci passthrough with a pci express usb2 card, I also use scsi
> > passthrough with a ultrium tape drive, usually running several windows
> > hvm's and a couple of 2.6.29 pv domU's as well, no problems.
> >
> 
> Hi Andy,
> 
> Where could I get this 2.6.29 from?
> 

I believe from here:
http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2

At least that URL he posted in the other recent dom0 kernel thread.

-- Pasi

Re: Future of xenbits Linux trees

[Andy Burns]

2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:

> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches,

Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.

> I use pci passthrough with a pci express usb2 card

is that PV or VT-d?

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
> 2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> 
> > I think 2.6.27 is already out of date and you should start with 2.6.29
> > using my rebased patches,
> 
> Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
> be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.
> 

Where did you hear that? 

I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..

Fedora 10 has 2.6.29 kernel in updates-testing, and Fedora 11 will be based
on 2.6.29 .. But dunno :)

-- Pasi

Re: Future of xenbits Linux trees

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 877 bytes --]

On Sun, 7 Jun 2009, Pasi Kärkkäinen wrote:

> On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
>> Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
>> be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.
>>
>
> Where did you hear that?
>
> I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..
>
> Fedora 10 has 2.6.29 kernel in updates-testing, and Fedora 11 will be based
> on 2.6.29 .. But dunno :)

2.6.27 has long term upstream support according to this post
https://www.redhat.com/archives/fedora-kernel-list/2009-January/msg00098.html
Also this post suggests that RHEL6 will be based on F10 and F11
https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html
though what this means with regard to which kernel RHEL6 will have I am 
not sure.

 	Michael Young

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

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

Re: Future of xenbits Linux trees

[Andy Burns]

2009/6/7 Pasi Kärkkäinen <pasik@iki.fi>:

> On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
>>
>> did I hear that it's likely RHEL6/CentOS6 will
>> be 2.6.27 based?
>
> Where did you hear that?

On a mailing list somewhere, but I couldn't find it to post a
reference, I've just had another look and I still can't find it,
perhaps I was mistaken.

> I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..

Actually I can see plenty of hints that RHEL6 will be ~2.6.30, so if
RH plans on having dom0 in RHEL6 then building some form of
"out-of-tree" coalition around 2.6.30+pvops patches would be nice, and
maybe dom0 will be accepted into mainstream before ~2.6.42 when RHEL7
gets frozen ;-)

Re: Future of xenbits Linux trees

[Christian Tramnitz]

Keir Fraser wrote:
> What do people think of this as a plan?

I'd opt for an approach based on the available 2.6.29 tree from Andrew 
but delayed until 2.6.30 is out.

Simple reason, there are so many fundamental changes in/before 2.6.29 
i.e. ext4 and in terms of video support (KMS, GEM) that anything before 
2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that 
will be the next tree that should have long-term (until pvops merges 
upstream, haha) support.
On the other hand it might make sense to use the same kernel version 
that RHEL6 will be using to take advantage of their (driver-) 
backporting efforts (not sure how heavily that has been utilized in 
2.6.18). Any insider infos from the RH guys here on the list what kernel 
that might be? ;-)



As a side-note, there is known issue with Andrew's tree not compiling on 
x86_32 with a recent gcc. If I remember correctly that was due to 
optimizations, further details here: 
http://forums.gentoo.org/viewtopic-p-5667545.html#5667545


Best regards,
    Christian

Re: Re: Future of xenbits Linux trees

[Keir Fraser]

On 05/06/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote:

> Simple reason, there are so many fundamental changes in/before 2.6.29
> i.e. ext4 and in terms of video support (KMS, GEM) that anything before
> 2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that
> will be the next tree that should have long-term (until pvops merges
> upstream, haha) support.

We don't need to wait for pv_ops to be merged. We just need it to have
near-enough feature parity. Actually now it supports HVM guests I'm tempted
to just move over to it. It would probably make sense to keep Jeremy as
gatekeeper for that tree, which will take some of his time. Otoh I'm not
sure spending 100% of your time banging your head against lkml is much fun.
:-)

Probably the major thing it's missing for a simple complete changeover is
ia64/Xen support. We could continue to point the ia64 build target at
linux-2.6.18-xen though.

 -- Keir

Re: Re: Future of xenbits Linux trees

[Dulloor]

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

Makes perfect sense to move over to pvops (in mainline) directly :
- Many of us have already used pvops-git and it works
- Other branches (2.6.27/29/30 or whatever) would be a single-chunk forward
port, with more scope for latent bugs (and no long-term benefits).
- We anyway need to make pvops happen. The more we wait, greater will be the
feature parity.
... and many more reasons.

Please make it happen !

-dulloor

On Fri, Jun 5, 2009 at 9:36 AM, Keir Fraser <keir.fraser@eu.citrix.com>wrote:

> On 05/06/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote:
>
> > Simple reason, there are so many fundamental changes in/before 2.6.29
> > i.e. ext4 and in terms of video support (KMS, GEM) that anything before
> > 2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that
> > will be the next tree that should have long-term (until pvops merges
> > upstream, haha) support.
>
> We don't need to wait for pv_ops to be merged. We just need it to have
> near-enough feature parity. Actually now it supports HVM guests I'm tempted
> to just move over to it. It would probably make sense to keep Jeremy as
> gatekeeper for that tree, which will take some of his time. Otoh I'm not
> sure spending 100% of your time banging your head against lkml is much fun.
> :-)
>
> Probably the major thing it's missing for a simple complete changeover is
> ia64/Xen support. We could continue to point the ia64 build target at
> linux-2.6.18-xen though.
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2309 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: Re: Future of xenbits Linux trees

[Ian Pratt]

> Makes perfect sense to move over to pvops (in mainline) directly :
> - Many of us have already used pvops-git and it works
> - Other branches (2.6.27/29/30 or whatever) would be a single-chunk
> forward port, with more scope for latent bugs (and no long-term benefits).
> - We anyway need to make pvops happen. The more we wait, greater will be
> the feature parity.
> ... and many more reasons.

One of the reasons cited for sticking on 2.6.18 was that it would hopefully encourage folk to use pv_ops if they wanted anything more modern. I'm not sure that worked out too well...

One argument for using 2.6.27 is that I believe it's the kernel used by SLES11, so there should be good availability of drivers backported to it. It strikes me it's not a bad plan to have two trees, one based off the latest stable enterprise distro (in this case SLES11), and the pvops tree based off the latest kernel.org release.

Ian

Re: Re: Future of xenbits Linux trees

[Gerd Hoffmann]

On 06/05/09 16:37, Ian Pratt wrote:
> One of the reasons cited for sticking on 2.6.18 was that it would
> hopefully encourage folk to use pv_ops if they wanted anything more
> modern. I'm not sure that worked out too well...

Making the pv_ops kernel the officially one in xen-unstable should work 
better I think.

> It strikes me it's not a bad plan to have two trees, one based
> off the latest stable enterprise distro (in this case SLES11), and
> the pvops tree based off the latest kernel.org release.

As you've noticed above having two trees (2.6.18 + pv_ops) didn't work 
out very well so far.  I doubt s/2.6.18/2.6.27/ will change that ...

cheers,
   Gerd

Re: Future of xenbits Linux trees

[Christian Tramnitz]

Keir Fraser wrote:
> We don't need to wait for pv_ops to be merged. We just need it to have
> near-enough feature parity. Actually now it supports HVM guests I'm tempted
> to just move over to it. It would probably make sense to keep Jeremy as
> gatekeeper for that tree, which will take some of his time. Otoh I'm not
> sure spending 100% of your time banging your head against lkml is much fun.
> :-)
> 
> Probably the major thing it's missing for a simple complete changeover is
> ia64/Xen support. We could continue to point the ia64 build target at
> linux-2.6.18-xen though.

Afaik pvops (even /next) also has no pci_backend support yet and even 
the pci_frontend support is mainly untested.
Both (front/back) work great with Andrew's 2.6.29 tree, although I 
haven't seen ANY reports of IA64 running off it.

I would also consider pvops to be a moving target (you know... lkml fun) 
so I wouldn't really base anything on it until the structure has been 
approved. Maintaining two different pvops lines (one with all changes as 
requested by mainline maintainers and one "stable") might to much of a 
burden if we already have a working 2.6.29 with (hopefully) not much 
work to do other than extensive testing before announcing it as 2.6.18 
successor.


Best regards,
    Christian

Re: Re: Future of xenbits Linux trees

[Gerd Hoffmann]

On 06/05/09 15:36, Keir Fraser wrote:
> On 05/06/2009 14:26, "Christian Tramnitz"<chris.ace@gmx.net>  wrote:
>
>> Simple reason, there are so many fundamental changes in/before 2.6.29
>> i.e. ext4 and in terms of video support (KMS, GEM) that anything before
>> 2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that
>> will be the next tree that should have long-term (until pvops merges
>> upstream, haha) support.
>
> We don't need to wait for pv_ops to be merged. We just need it to have
> near-enough feature parity. Actually now it supports HVM guests I'm tempted
> to just move over to it.

Go ahead!  It is really time to stop forward-porting stuff.  The time is 
much better spent in adding the missing features to pv_ops/dom0.  Also 
just after the 3.4 release is the perfect moment for that move, 3.5 
should be able to ship with a pv_ops based kernel then.

cheers,
   Gerd

AW: Re: Re: Future of xenbits Linux trees

[Carsten Schiers]

> Go ahead!  It is really time to stop forward-porting stuff.  The time 
is 
> much better spent in adding the missing features to pv_ops/dom0.  Also 

> just after the 3.4 release is the perfect moment for that move, 3.5 
> should be able to ship with a pv_ops based kernel then.

I'd vote for that, too. Whatever comes out of that discussion on 
"coolness"
on lkml ;o), I guess pv_ops is what will be the outcome. Inside or 
outside
the linux kernel tree.

What I'd like to add is that I would prefer a better tagging of the 
kernel 
repo to identify subversion of the kernel that belong to a certain 
version 
of Xen, whatever kernel that might be. Fixes and improvements are 
happening
so quickly that on the pure user's side the combination can make a 
difference,
no matter how much effort you put in to keep it independent. 

BR,
Carsten.

Re: AW: Re: Re: Future of xenbits Linux trees

[Keir Fraser]

On 05/06/2009 18:58, "Carsten Schiers" <carsten@schiers.de> wrote:

> What I'd like to add is that I would prefer a better tagging of the
> kernel 
> repo to identify subversion of the kernel that belong to a certain
> version 
> of Xen, whatever kernel that might be. Fixes and improvements are
> happening
> so quickly that on the pure user's side the combination can make a
> difference,
> no matter how much effort you put in to keep it independent.

As I've said so many times, the kernel version and Xen version are *not*
tied. We don't do kernel releases tied to Xen versions, at all.

 -- Keir

AW: Re: AW: Re: Re: Future of xenbits Linux trees

[Carsten Schiers]

I know and it's not my decision. But my problems on TSC skew disappeared 
only
by using a combination of recent version pulled at approximately the 
same time. 

You might argue that cpufreq=dom0-kernel moves functionality that should 
belong
to xen into the Dom0 kernel. Yes, you're right. From that point of view 
I have
nothing to put in the balance.

BR,
Carsten.

-----Ursprüngliche Nachricht-----
Von: Keir Fraser [mailto:keir.fraser@eu.citrix.com] 
Gesendet: Freitag, 5. Juni 2009 20:49
An: Carsten Schiers; kraxel
Cc: chris.ace; jeremy; xen-devel; yamahata
Betreff: Re: AW: Re: [Xen-devel] Re: Future of xenbits Linux trees

On 05/06/2009 18:58, "Carsten Schiers" <carsten@schiers.de> wrote:

> What I'd like to add is that I would prefer a better tagging of the
> kernel 
> repo to identify subversion of the kernel that belong to a certain
> version 
> of Xen, whatever kernel that might be. Fixes and improvements are
> happening
> so quickly that on the pure user's side the combination can make a
> difference,
> no matter how much effort you put in to keep it independent.

As I've said so many times, the kernel version and Xen version are *not*
tied. We don't do kernel releases tied to Xen versions, at all.

 -- Keir