Stas Sergeev <s...@list.ru> writes: > 19.04.2012 06:05, Eric W. Biederman wrote: >> So let me point out that Andi is no longer the x86_64 maintainer, >> and one of the big policy changes that happened with the turn over in >> maintainership is that workarounds for weird cpus bugs (if the can be >> implemented cleanly) are now considered. >> >> So it might be worth revisiting this issue. > The problem with dosemu-specific fixes is just that: they > are dosemu-specific. :) I wonder if kernel people are going > to add the dosemu-specific workarounds these days. > When I was advocating for such a workaround in the i386 > code, I was saying that it is good for...... wine. :)) But with > x86-64 this cheat won't work: wine uses dosbox for > executing DOS code on x86-64 AFAIK, and for running the > 32bit binaries it uses a multilib approach and a purely 32bit > code, so it is likely they won't buy such an argument any more. > We should still try, but I just don't expect a success unless > the implementation is really trivial. At least the GDT-patching > approach employed in a i386 code will unlikely to work since > the base is ignored on x86-64 IIRC.
Well you could always start a project to write native 16bit programs to guarantee you stay in the cache ;) I expect gunzip would scream in such a scenario. gunzip certainly used to scream on dos. In general bugs are bugs. Cpu errata is cpu erratta and if someone is crazy enough to write a clean patch it is likely to be accepted. A lot depends on the maintainability of the solution. >> I don't expect a 64k aligned stack would be a very easy perhaps the >> convoluted segment thing if it doesn't slow down kernel fast paths. > The fast path should only check whether the SS is from LDT, > so the slowdown can be avoided. But I wonder if something > else than the separate 16bit stack can be used to avoid the > problems. Such a stack was sitting in the i386 code for a few > years and people were annoyed so I had to change it to the > 32bit stack plus GDT patching. But if GDT patching wont work, > then I guess the 16bit stack is the only solution, and it is > rather unlikely to be accepted to x86-64... > So can anyone find a trivial solution to this puzzle or not? :) > Ask AMD for the microcode update? :) I thought it was an Intel bug? Is it possible you can point me to the errata? I only half understand what the bug is. Eric ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
