qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: tsnsaito
Subject: Re: [Qemu-devel] [PATCH 0/4] SPARC64: Implement sparcv9 ldfa/stfa instructions
Date: Thu, 14 Jul 2011 18:13:30 +0900
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj$(D+W(B) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO)

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.

> > - 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.

---- 
Tsuneo Saito <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]