Re: What do we need to do to hit 2.6.19?

Re: What do we need to do to hit 2.6.19?

[Andi Kleen]

On Friday 04 August 2006 20:34, Jeremy Fitzhardinge wrote:
> Chris said, and I agree, that we should try to get the basic PV-ops 
> infrastructure stuff into 2.6.19.  To me this means being able to run a 
> kernel native with CONFIG_PARAVIRT, and see little or no functional or 
> performance degradation.  What do we need to do to get there:
> 
>     * fix the slowdown bug, which seems to be something to do with
>       rdmsr/wrmsr on SMP systems
>     * work out how to handle all the low-level system interfaces, like
>       ACPI, PnP BIOS, APM
>     * what else?

You're already too late for most of this. The merge window will
open in the forseeable future and you don't have had significant
-mm* or x86_64-* testing yet and in general stuff is still
very fresh.

Maybe we can get some basic "obvious" stuff like a few 
macro substitutions in (if you submit them properly), but probably not 
the full support.

-Andi

Re: What do we need to do to hit 2.6.19?

[Chris Wright]

* Andi Kleen (ak@suse.de) wrote:
> On Friday 04 August 2006 20:34, Jeremy Fitzhardinge wrote:
> > Chris said, and I agree, that we should try to get the basic PV-ops 
> > infrastructure stuff into 2.6.19.  To me this means being able to run a 
> > kernel native with CONFIG_PARAVIRT, and see little or no functional or 
> > performance degradation.  What do we need to do to get there:
> > 
> >     * fix the slowdown bug, which seems to be something to do with
> >       rdmsr/wrmsr on SMP systems
> >     * work out how to handle all the low-level system interfaces, like
> >       ACPI, PnP BIOS, APM
> >     * what else?
> 
> You're already too late for most of this. The merge window will
> open in the forseeable future and you don't have had significant
> -mm* or x86_64-* testing yet and in general stuff is still
> very fresh.
> 
> Maybe we can get some basic "obvious" stuff like a few 
> macro substitutions in (if you submit them properly), but probably not 
> the full support.

I don't agree.  We've got the first bit of obvious stuff posted and
queued up.  There's a bit more, then the final piece is #ifdef that means
none of the new code will even get compiled for non CONFIG_PARAVIRT users
(mark it as experimental, default = N, etc).  Then we have a safe place
to push things up w/out disturbing others.  IOW, at that point it's like
a new device driver, or fs, or arch....those can merge quite late.
Not saying it's not agressive, but I don't think it's obviously too
late.

thanks,
-chris

Re: What do we need to do to hit 2.6.19?

[Andi Kleen]

> I don't agree.  We've got the first bit of obvious stuff posted

For some value of "posted" that includes destroying it with rogue MIME 
encoding.

> and 
> queued up.  

Yes and you missed the testing phase so far completely.

Merge window is not really the time to push in lots of fresh untested 
code.

-Andi

Re: What do we need to do to hit 2.6.19?

[Chris Wright]

* Jeremy Fitzhardinge (jeremy@goop.org) wrote:
> Chris said, and I agree, that we should try to get the basic PV-ops 
> infrastructure stuff into 2.6.19.  To me this means being able to run a 
> kernel native with CONFIG_PARAVIRT, and see little or no functional or 
> performance degradation.  What do we need to do to get there:
> 
>    * fix the slowdown bug, which seems to be something to do with
>      rdmsr/wrmsr on SMP systems

I believe this is fixed now, at least it's booting fine on my smp box now.

 #define wrmsr_safe(msr,a,b) ({                                \
-      u64 _l = ((u64)(a) << 32) | (b);                        \
+      u64 _l = ((u64)(b) << 32) | (a);                        \
       paravirt_ops.write_msr((msr),_l);                       \
 })

thanks,
-chris

Re: What do we need to do to hit 2.6.19?

[Jeremy Fitzhardinge]

Chris Wright wrote:
> I believe this is fixed now, at least it's booting fine on my smp box now.
>
>  #define wrmsr_safe(msr,a,b) ({                                \
> -      u64 _l = ((u64)(a) << 32) | (b);                        \
> +      u64 _l = ((u64)(b) << 32) | (a);                        \
>        paravirt_ops.write_msr((msr),_l);                       \
>  })
>   

But, but 'a' is obviously the msw ;-). 

Neato.  I'll give it a spin later this evening.

    J