Re: [Qemu-devel] [PATCH 0/4] SPARC64: Implement sparcv9 ldfa/stfa instructions

[Blue Swirl]

On Thu, Jul 14, 2011 at 12:13 PM,  <address@hidden> wrote:
> At Thu, 14 Jul 2011 09:38:18 +0200,
> Artyom Tarasenko wrote:
>> On Thu, Jul 14, 2011 at 5:13 AM,  <address@hidden> wrote:
>> > At Wed, 13 Jul 2011 19:34:10 +0300,
>> > Blue Swirl wrote:
>> >> On Wed, Jul 13, 2011 at 3:48 PM,  <address@hidden> 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.