On Tuesday 13 November 2007 01:11, H. Peter Anvin wrote: > Andi Kleen wrote: > >> The *real* fix for this is almost certainly to just get rid of the > >> 64-bit code entirely, and use the 32-bit code as the base for one single > >> unified setup. > > > > That would likely break the ABI. x86-64 ABI is completely different here > > -- no ibcs, just pure x86 ISA. > > Different ABIs clearly have to be handled,
Well all four cases are quite different. > but I don't think that is a > huge deal. The i387 code overall (not just asm/i387.h) is very > different, Yes because x86-64 is vastly simpler. e.g. the 64bit path does not touch the state itself at all. And all the state convert code moved into the compat layer only. There were also various other cleanups. Also 64bit e.g. defers some of the checking to the context switch, which also simplifies things. > though, and I find it unlikely that a properly unified code > is going to be ready and working in the 2.6.24 timeframe. To be honest it is unclear to me how you can do better than direct FXSAVE from/to user space on 64bit. Sure you could put a manual convert pass inbetween like i386, but that would be rather pointless because it matches 1:1 and in fact would make the code to be worse (no transparent support of future FXSAVE extensions) . Not sure what tripped Linus up so much either. Was it the broken white space? > I'm exploring > if a partial merge with high confidence level is feasible; either way, a > proper merge for 2.6.25 is probably the right thing. At least on 64bit the result would be probably more complicated and likely slower code. If anything it might make sense to add a few more of the 64bit improvements to 32bit (e.g. delayed exception checking). The direct FXSAVE path cannot be moved over because it would break the ABI, otherwise I would have done that long ago. BTW if you're looking for real fixes to do iirc some of the FPU context switch workarounds are missing in KVM which does mostly its own thing currently. -Andi - 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/
