On Mon, Aug 20, 2007 at 03:57:38PM +0200, Nicolas Schichan wrote: > The updated patch only uses __flush_cache_all(). Applied, thanks. > > There is a hazard barrier missing here. > > Just for my culture, could you please specify which kind of barrier macro > should I use here ? should it be a back_to_back_c0_hazard() ? According to the MIPS architecture, a mfc0 instruction that is immediately following a mtc0 instruction where both are accessing the same cp0 register, has undefined operation. Not all processors have this hazard and for those those which have it the resolution before version 2 of the architecture did differ between MIPS implementation. back_to_back_c0_hazard() will solve this problem. For example: write_c0_status(read_c0_status() & ~ ST0_BEV); write_c0_status(read_c0_status() | ST0_IE); could possibly be compiled into such a mtc0 mfc0 sequence. Throwing in a back_to_back_c0_hazard() line will fix that. write_c0_status(read_c0_status() & ~ ST0_BEV); back_to_back_c0_hazard(); write_c0_status(read_c0_status() | ST0_IE); On a modern processor back_to_back_c0_hazard() will expand into a EHB, on an antique to whatever serves the equivalent job. Changing Config.K0 also creates an "instruction hazard". Even when the mtc0 has been graduated in the pipeline it needs to be ensured that no instructions are being fetched and executed based on the old value. My description is somewhat to short to be accurate, I suggest you read up on it in the MIPS R2 architecture specification, See MIPS Run and of course in the manual for your specific processor. > Hoewever I so feel a bit unsafe now because D-Cache is not wrote-back and > I-Cache is not invalidated in relocate_kernel.S, before jumping to the new > kernel. This happens to work on my board, but I think that it is mostly > because of luck. Maybe using KSEG1 or XKPHYS (not sure about this one, I am > not familiar with 64bit mips) when fixing the indirection list addresses > should be safer. KSEG1 would have the same issues as KSEG0 configured to uncached. But really, why making things more complicated than required. A flush should do the trick. Another open end in your patch would be SMP; normally Linux expects that on bootup all processors are under firmware control but that is not the case when a new kernel is initializing after being kexeced. Ralf
