Guys currently I am horrified by the ease at which I can find bugs in the pending paravirtualization patches. I have barely even looked at arch/i386 in the -mm tree and it feels like I am tripping over significant bugs left and right. Because no one has heeded my advice and put in a proper platform layer on arch/i386 and we are instead doing a half baked job with paravirt_ops it is still trivially easy to miss the fact that subarchitectures do something different, and thus it is easy to miss when you break a sub architecture on arch/i386. Not that the paravirtuailzation patches are even safe on the primary arch/i386. To some extent I grant with major changes a little goofing up on pending patches is to be expected, but it would be nice if things were restructured to make it harder to miss the subarchitectures on arch/i386. The patch known as x86_64-mm-use-per-cpu-gdt-immediately-upon-boot on -mm currently breaks voyager smp support in some very obvious ways. Making init_gdt a function which is called from voyager_smp.c static in smpboot.c a file that is not even used on voayger is an obvious one. Adding start_pda and not setting it in voyager_smp is another. Rusty do you think you can address this? Eric
Eric W. Biederman wrote:> Guys currently I am horrified by the ease at which I can find > bugs in the pending paravirtualization patches. I have barely > even looked at arch/i386 in the -mm tree and it feels like > I am tripping over significant bugs left and right. >Well, I appreciate any and all review comments you have to make.> Because no one has heeded my advice and put in a proper platform > layer on arch/i386 and we are instead doing a half baked job > with paravirt_ops it is still trivially easy to miss the > fact that subarchitectures do something different, and thus > it is easy to miss when you break a sub architecture on > arch/i386. >Yes. Though in many ways paravirt_ops is approaching that platform layer. In the next round of work, it might be worth renaming it and actually using it to subsume the subarch mechanism into something that can deal with any architecture at runtime. While this hasn't been an explicit goal of the current round of work, I've tried to point things in that direction where I can (smp_ops and reboot_ops being specific examples of that). But you're right; we've been fairly cavalier about Voyager in particular, with the hope that James' machine will die before he notices we've broken the build. (Or perhaps it has, and he just keeps building voyager kernels to torment us.)> Not that the paravirtuailzation patches are even safe on the > primary arch/i386. >Are you referring to the PSE pagetable setup problem we've been discussing, or do you have something else in mind?> To some extent I grant with major changes a little goofing up on > pending patches is to be expected, but it would be nice if > things were restructured to make it harder to miss the > subarchitectures on arch/i386. > > The patch known as x86_64-mm-use-per-cpu-gdt-immediately-upon-boot > on -mm currently breaks voyager smp support in some very obvious ways. > > Making init_gdt a function which is called from voyager_smp.c static > in smpboot.c a file that is not even used on voayger is an obvious > one. > > Adding start_pda and not setting it in voyager_smp is another. > > Rusty do you think you can address this?Well, it will probably need to be done after the following patches which get rid of the PDA altogether. But the boot-time setup is now pretty simple, so it should just be a matter of putting a couple of init_gdts in the right places. (It is non-static now too.) J
On Sat, 2007-04-28 at 11:39 +0200, Andi Kleen wrote:> > Last test was 2.6.21-rc7, where I fixed the non-WP thing. The > > FP-emulator seems to work. > > > > Which kind of breakage is new ? > > Nothing known so far, but there were a lot of changes recently. It would be good > if you could retest mainline on that box once the x86 tree is merged up.I added that box to my auto test farm of bizarre hardware already, so I will notice breakage quite fast. tglx
On Sat, 2007-04-28 at 00:40 -0600, Eric W. Biederman wrote:> Guys currently I am horrified by the ease at which I can find > bugs in the pending paravirtualization patches. I have barely > even looked at arch/i386 in the -mm tree and it feels like > I am tripping over significant bugs left and right. > > Because no one has heeded my advice and put in a proper platform > layer on arch/i386 and we are instead doing a half baked job > with paravirt_ops it is still trivially easy to miss the > fact that subarchitectures do something different, and thus > it is easy to miss when you break a sub architecture on > arch/i386.I got a bit tired of trying to be proactive. The last time was for the %gs per cpu thing, which I saw coming. The basic problem is that there's no well organised git tree I can pull from and bisect to trace problems. My strategy now is to wait for the merge window to close and then go around sweeping up the mess and yelling at the offenders ... it's what all the non-x86 architectures do, and it's definitely an easier process.> Not that the paravirtuailzation patches are even safe on the > primary arch/i386. > > To some extent I grant with major changes a little goofing up on > pending patches is to be expected, but it would be nice if > things were restructured to make it harder to miss the > subarchitectures on arch/i386. > > The patch known as x86_64-mm-use-per-cpu-gdt-immediately-upon-boot > on -mm currently breaks voyager smp support in some very obvious ways. > > Making init_gdt a function which is called from voyager_smp.c static > in smpboot.c a file that is not even used on voayger is an obvious > one. > > Adding start_pda and not setting it in voyager_smp is another. > > Rusty do you think you can address this?James