On Thu, Jul 14, 2011 at 12:13 PM, <tsnsa...@gmail.com> wrote: > At Thu, 14 Jul 2011 09:38:18 +0200, > Artyom Tarasenko wrote: >> On Thu, Jul 14, 2011 at 5:13 AM, <tsnsa...@gmail.com> wrote: >> > At Wed, 13 Jul 2011 19:34:10 +0300, >> > Blue Swirl wrote: >> >> On Wed, Jul 13, 2011 at 3:48 PM, <tsnsa...@gmail.com> wrote: >> >> > At Wed, 13 Jul 2011 13:09:28 +0100, >> >> > Mark Cave-Ayland wrote: >> >> >> >> Nice series! >> >> >> >> May I ask what have you used as a test case to discover the problem? >> >> >> > >> >> >> > I found the problem when I was trying to run the linux/sparc64 >> >> >> > kernel. >> >> >> > It seemed that copy_to_user() did not work as expected. >> >> >> >> >> >> That's good to hear. How far have you managed to get a 64-bit Linux >> >> >> kernel to boot to date? >> >> > >> >> > With dirty hacks other than the ldfa/stfa fixes, I have managed >> >> > to get the busybox shell prompt using a kernel with initramfs. >> >> > I'm planning to send other fixes after cleaning them up. >> >> >> >> Great! In which areas are the hacks needed? >> > >> > Roughly speaking I've added/changed the following so far: >> > - %fprs register dirty bits support >> >> O, that's interesting. Does glibc use it? > > The linux kernel saves FPU registers context based on %fprs dirty bits. > We need to implement these bits in order to make context switches > work properly.
This could be implemented so that each instruction that writes to FPU registers updates the dirty bits. A more advanced version could try to do this more lazily (end of basic block or after any exception generating instruction) but that may be tricky. >> > - hardware interrupt handing (both interrupt controller and cpu side) >> > also needed to modify the openbios. >> >> Nice. A lot of work indeed. >> >> > - nonfaulting load ASI >> > glibc memcpy seems to use nonfaulting loads >> >> You mean other than the implemented 0x82/83 and 0x8a/8b ones, or that >> the current implementation is buggy? > > The softmmu version of current implementation is incorrect. > Nonfaulting loads should generate exceptions in the same way as > normal loads. The CPU hardware should not return zero automatically > if no memory mapping exists. The system software is responsible for > nonfaulting loads to read zero if no mapping is availale. > > The differences between nonfaulting loads and normal loads are: > - that DSFSR.NF bit is set for nonfaulting loads on MMU faults. > - the result of loads on memory region mapped by TTEs with NFO bit set. I hope this is documented somewhere.
