Re: [PATCH 0/10] Tree fixes for PARAVIRT

2008-01-22 Thread Ingo Molnar

* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:

> On Jan 18, 2008 8:02 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> >
> > > > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y.
> > > > Which means you did not even build-test it on 32-bit, let alone boot
> > > > test it...
> > >
> > > Why are we rushing so much to do 64-bit paravirt that we are breaking
> > > working configurations?  If the developement is going to be this
> > > chaotic, it should be done and tested out of tree until it can
> > > stabilize.
> >
> > what you see is a open feedback cycle conducted on lkml. People send
> > patches for arch/x86, and we tell them if it breaks something. The bug
> > was found before i pushed out the x86.git devel tree (and the fix is
> > below - but this shouldnt matter to you because the bug never hit a
> > public x86.git tree).
> >
> > Ingo
> >
> Other than this, it seems to build and boot fine.
> 
> Do you want me to resend ?

no, this was the only small problem i found, your series looks good to 
me and is included in latest x86.git.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/10] Tree fixes for PARAVIRT

2008-01-18 Thread Glauber de Oliveira Costa
On Jan 18, 2008 8:02 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
>
> > > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y.
> > > Which means you did not even build-test it on 32-bit, let alone boot
> > > test it...
> >
> > Why are we rushing so much to do 64-bit paravirt that we are breaking
> > working configurations?  If the developement is going to be this
> > chaotic, it should be done and tested out of tree until it can
> > stabilize.
>
> what you see is a open feedback cycle conducted on lkml. People send
> patches for arch/x86, and we tell them if it breaks something. The bug
> was found before i pushed out the x86.git devel tree (and the fix is
> below - but this shouldnt matter to you because the bug never hit a
> public x86.git tree).
>
> Ingo
>
Other than this, it seems to build and boot fine.

Do you want me to resend ?
-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/10] Tree fixes for PARAVIRT

2008-01-18 Thread Jeremy Fitzhardinge

Zachary Amsden wrote:

Why are we rushing so much to do 64-bit paravirt that we are breaking
working configurations?  If the developement is going to be this
chaotic, it should be done and tested out of tree until it can
stabilize.
  


x86.git is out of the mainline tree, and it seems to be working fairly 
smoothly.  I've come to appreciate the "lots of small patches with quick 
turnaround" model that Ingo has been pushing.



I do not like having to continuously retest and review the x86 branch
because the paravirt-ops are constantly in flux and the 32-bit code
keeps breaking.
  


Most of the activity is pure unification, with paravirt being part of 
that.  It doesn't help that it increases the CONFIG_ combinatorial 
explosion, but "make randconfig" shakes things out fairly quickly.



We won't be doing 64-bit paravirt-ops for exactly this reason - is there
a serious justification from the performance angle on modern 64-bit
hardware?  If not, why justify the complexity and hackery to Linux?
  


A big part of the rationale is to unify 32 and 64 bit, so that paravirt 
isn't a gratuitous difference between the two.  Also, 32 and 64 bit Xen 
have almost identical interface requirements, so the work is making 
64-bit Xen progress (and lguest64, of course).


   J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/10] Tree fixes for PARAVIRT

2008-01-18 Thread Ingo Molnar

* Zachary Amsden <[EMAIL PROTECTED]> wrote:

> > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y. 
> > Which means you did not even build-test it on 32-bit, let alone boot 
> > test it...
> 
> Why are we rushing so much to do 64-bit paravirt that we are breaking 
> working configurations?  If the developement is going to be this 
> chaotic, it should be done and tested out of tree until it can 
> stabilize.

what you see is a open feedback cycle conducted on lkml. People send 
patches for arch/x86, and we tell them if it breaks something. The bug 
was found before i pushed out the x86.git devel tree (and the fix is 
below - but this shouldnt matter to you because the bug never hit a 
public x86.git tree).

Ingo

Index: linux/include/asm-x86/paravirt.h
===
--- linux.orig/include/asm-x86/paravirt.h
+++ linux/include/asm-x86/paravirt.h
@@ -619,6 +619,7 @@ static inline void write_cr4(unsigned lo
PVOP_VCALL1(pv_cpu_ops.write_cr4, x);
 }
 
+#ifdef CONFIG_X86_64
 static inline unsigned long read_cr8(void)
 {
return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr8);
@@ -628,6 +629,7 @@ static inline void write_cr8(unsigned lo
 {
PVOP_VCALL1(pv_cpu_ops.write_cr8, x);
 }
+#endif
 
 static inline void raw_safe_halt(void)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/10] Tree fixes for PARAVIRT

2008-01-18 Thread Zachary Amsden
On Fri, 2008-01-18 at 22:37 +0100, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 
> > > The first fix is not even specific for PARAVIRT, and it's actually 
> > > preventing the whole tree from booting.
> > 
> > on CONFIG_EFI, indeed :)
> 
> but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y. Which 
> means you did not even build-test it on 32-bit, let alone boot test 
> it...

Why are we rushing so much to do 64-bit paravirt that we are breaking
working configurations?  If the developement is going to be this
chaotic, it should be done and tested out of tree until it can
stabilize.

I do not like having to continuously retest and review the x86 branch
because the paravirt-ops are constantly in flux and the 32-bit code
keeps breaking.

We won't be doing 64-bit paravirt-ops for exactly this reason - is there
a serious justification from the performance angle on modern 64-bit
hardware?  If not, why justify the complexity and hackery to Linux?

Zach

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/10] Tree fixes for PARAVIRT

2008-01-18 Thread Ingo Molnar

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> > The first fix is not even specific for PARAVIRT, and it's actually 
> > preventing the whole tree from booting.
> 
> on CONFIG_EFI, indeed :)

but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y. Which 
means you did not even build-test it on 32-bit, let alone boot test 
it...

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/10] Tree fixes for PARAVIRT

2008-01-18 Thread Ingo Molnar

* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:

> 
> This small series provides some more fixes towards the goal to have 
> the PARAVIRT selectable for x86_64. After that, just some more small 
> steps are needed.

thanks, applied.

> The first fix is not even specific for PARAVIRT, and it's actually 
> preventing the whole tree from booting.

on CONFIG_EFI, indeed :)

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 0/10] Tree fixes for PARAVIRT

2008-01-18 Thread Glauber de Oliveira Costa
Hi,

This small series provides some more fixes towards the goal
to have the PARAVIRT selectable for x86_64. After that, just
some more small steps are needed.

The first fix is not even specific for PARAVIRT, and it's actually
preventing the whole tree from booting.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/