xen patches are in 2.6.37

xen patches are in 2.6.37

[M A Young]

Linus has merged branch 'stable/xen-pcifront-0.8.2' of 
git://git./linux/kernel/git/konrad/xen
   and branch 'for-linus' of 
git://xenbits.xen.org/people/sstabellini/linux-pvhvm at
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=18cb657ca1bafe635f368346a1676fb04c512edf

 	Michael Young

Re: xen patches are in 2.6.37

[Pasi Kärkkäinen]

On Fri, Oct 29, 2010 at 08:36:54AM +0100, M A Young wrote:
> Linus has merged branch 'stable/xen-pcifront-0.8.2' of  
> git://git./linux/kernel/git/konrad/xen
>   and branch 'for-linus' of  
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm at
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=18cb657ca1bafe635f368346a1676fb04c512edf
>

Congratulations to everyone involved!! Great job.

So what's the next step for dom0 upstreaming? backend drivers? 

-- Pasi

Re: xen patches are in 2.6.37

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Fri, 29 Oct 2010, Pasi Kärkkäinen wrote:
> On Fri, Oct 29, 2010 at 08:36:54AM +0100, M A Young wrote:
> > Linus has merged branch 'stable/xen-pcifront-0.8.2' of  
> > git://git./linux/kernel/git/konrad/xen
> >   and branch 'for-linus' of  
> > git://xenbits.xen.org/people/sstabellini/linux-pvhvm at
> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=18cb657ca1bafe635f368346a1676fb04c512edf
> >
> 
> Congratulations to everyone involved!! Great job.
> 

Thanks :)

> So what's the next step for dom0 upstreaming? backend drivers? 
 
Yes, backend drivers would be the next step to reach the point when we
can actually boot a VM.
Help in this area is always welcome :)

[-- 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 patches are in 2.6.37

[Konrad Rzeszutek Wilk]

> > So what's the next step for dom0 upstreaming? backend drivers? 
>  
> Yes, backend drivers would be the next step to reach the point when we
> can actually boot a VM.

And stabilizing work, so fixing all of those little things that crep up with
initial bootup (Xserver/Xorg, PAT, MTRR, DRM, KMS, ACPIs).

> Help in this area is always welcome :)

Oh yes, keep on sending those bug or even success reports.

Re: xen patches are in 2.6.37

[Bruce Edge]

On Fri, Oct 29, 2010 at 7:45 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> > So what's the next step for dom0 upstreaming? backend drivers?
>>
>> Yes, backend drivers would be the next step to reach the point when we
>> can actually boot a VM.
>
> And stabilizing work, so fixing all of those little things that crep up with
> initial bootup (Xserver/Xorg, PAT, MTRR, DRM, KMS, ACPIs).
>
>> Help in this area is always welcome :)
>
> Oh yes, keep on sending those bug or even success reports.

Konrad,
We've been using your pv/pcifront-0.8.1 for a couple of weeks now and
while it's (conversion to pvops) forced us to remove some bare-metal
optimizations in our driver code, the porting is going very well.
Additionally we have source level debugging of kernel modules with
gdbsx and functional cores for post mortem analysis with crash
working. Combined these items provide everything necessary for
successful product development.
The fact that has been accepted into the mainline is fantastic news.

Thanks for all your help along the way.

-Bruce

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

Re: xen patches are in 2.6.37

[Jeremy Fitzhardinge]

 On 10/29/2010 02:46 AM, Pasi Kärkkäinen wrote:
> On Fri, Oct 29, 2010 at 08:36:54AM +0100, M A Young wrote:
>> Linus has merged branch 'stable/xen-pcifront-0.8.2' of  
>> git://git./linux/kernel/git/konrad/xen
>>   and branch 'for-linus' of  
>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm at
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=18cb657ca1bafe635f368346a1676fb04c512edf
>>
> Congratulations to everyone involved!! Great job.
>
> So what's the next step for dom0 upstreaming? backend drivers? 

Yes, we need to come up with a set of backends that are upstreamable.

There's also a bunch of auxillary things like ACPI power management, CPU
hotplug, etc which need to be adapted and put through the upstreaming
wringer.

My thoughts about development from now are:

Main Xen development will migrate to the (newly created) xen/next-2.6.37
branch.  At the moment this is more or less exactly upstream, with a
couple of little fixes added.

xen/next-2.6.32 (= xen/stable-2.6.32.x) will move to a more maintenance
state.  They'll be maintained for as long as kernel.org maintains
2.6.32, but the bar for including patches will be higher (definitely
bugfixes, new features if they're not too intrusive, etc).

Therefore the development model will tend towards developing on current
kernels and backporting where necessary, rather than working on old
kernels and forward-porting.

    J

Re: xen patches are in 2.6.37

[Josip Rodin]

On Fri, Oct 29, 2010 at 09:49:57AM -0700, Jeremy Fitzhardinge wrote:
>  On 10/29/2010 02:46 AM, Pasi Kärkkäinen wrote:
> > On Fri, Oct 29, 2010 at 08:36:54AM +0100, M A Young wrote:
> >> Linus has merged [...]
> >>
> > Congratulations to everyone involved!! Great job.
> >
> > So what's the next step for dom0 upstreaming? backend drivers? 
> 
> Yes, we need to come up with a set of backends that are upstreamable.
> 
> There's also a bunch of auxillary things like ACPI power management, CPU
> hotplug, etc which need to be adapted and put through the upstreaming
> wringer.

Great work, everyone. This has been a very diligent effort.

I laughed out loud when I saw Greg's "but this isn't dom0?!" comment, though
I figured you all must have gotten really annoyed seeing that; yet it was
handled very gracefully.

> My thoughts about development from now are:
> 
> Main Xen development will migrate to the (newly created) xen/next-2.6.37
> branch.  At the moment this is more or less exactly upstream, with a
> couple of little fixes added.

Are you going to make a temporary branch where you'll just slap on the
missing code (even the non-upstreamable parts), just so we can test the full
Xen dom0 stack in the current circumstances? Upstream kernel has undergone
many changes since .32 and it stands to reason that there are other bugs to
flush out, unrelated to code upstreamability.

-- 
     2. That which causes joy or happiness.

Re: xen patches are in 2.6.37

[Thomas Goirand]

On 10/29/2010 03:36 PM, M A Young wrote:
> Linus has merged branch 'stable/xen-pcifront-0.8.2' of
> git://git./linux/kernel/git/konrad/xen
>   and branch 'for-linus' of
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm at
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=18cb657ca1bafe635f368346a1676fb04c512edf
>
>
>     Michael Young
Congrats to everyone, Stefano, Konrad, Jeremy. I'm really impressed
that you guys never gave up. I'd be looking forward to have backend
drivers fully working.

Over these last 2 years, it has been very hard to convince people that
"no, RedHat isn't Linux, and the fact that they dumped Xen is a non-
event". Now, for sure, it's going to be very easy to explain that this
was pure marketing stupidity, and that they will have hard time to...
make patches to remove Xen support!!! :) Now, I'll be curious to see
if they will continue with more silliness and refuse to include the Xen
hypervisor and userland tools in their distro, based purely on
marketing and past (buzz) announcement.

Thanks again for the huge work,
Cheers,

Thomas Goirand

Re: xen patches are in 2.6.37

[Jeremy Fitzhardinge]

 On 10/29/2010 11:10 AM, Josip Rodin wrote:
> Are you going to make a temporary branch where you'll just slap on the
> missing code (even the non-upstreamable parts), just so we can test the full
> Xen dom0 stack in the current circumstances? Upstream kernel has undergone
> many changes since .32 and it stands to reason that there are other bugs to
> flush out, unrelated to code upstreamability.

Yes, I want to keep a full-featured Xen kernel tracking upstream
releases.  But I'd like to put a strong emphasis on making sure that
components which must be upstreamed (ie, to get a useful system), or are
very close to upstreamable should be kept in an upstreamable form.

In general, stuff that I think is plausible for upstream, or actually
being upstreamed, will be in upstream/*.   Those branches are also
highly dynamic (rebasing, etc), so never use them as the base for your
own branches...

    J