Re: [PATCH v2 24/30] linux-user/openrisc: Use force_sig_fault, force_sigsegv_for_addr

From: Stafford Horne <shorne@gmail.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Laurent Vivier <laurent@vivier.eu>
Subject: Re: [PATCH v2 24/30] linux-user/openrisc: Use force_sig_fault, force_sigsegv_for_addr
Date: Wed, 22 Sep 2021 05:26:23 +0900	[thread overview]
Message-ID: <YUo/7zXG993jbOVQ@antec> (raw)
In-Reply-To: <a031dc23-f7e6-49a6-ae90-d563172849ba@linaro.org>

On Sun, Sep 19, 2021 at 10:49:26AM -0700, Richard Henderson wrote:
> On 8/24/21 10:17 AM, Peter Maydell wrote:
> > I think that EXCP_RANGE should for us be unreachable in user-only
> > mode (because it can only happen if the relevant bits in SR are
> > set, and SR is writeable only in supervisor mode, and its starting
> > value doesn't set these bits). So we could just delete the EXCP_RANGE
> > handling and let it hit the default g_assert_not_reached() case.
> 
> If I also disable the SR case from gdbstub.
> 
> > EXCP_FPE is more tricky -- this happens for FP exceptions, where
> > the enabling bit is in the FPCSR, which does appear to be writeable
> > from user mode. So either:
> >   * our mtspr is wrong and should either be not allowing writes
> >     to FPCSR in usermode (or at least sanitizing them)
> >   * the Linux kernel for openrisc is wrong, because a userspace
> >     program that sets FPCSR.FPEE can make it run into unhandled_exception()
> >     and die(), and it should be doing something else, like delivering
> >     a suitable SIGFPE
> 
> I believe the kernel to be buggy.  But it also point to the fact that no one
> has written fenv.h for or1k for musl, so no one has tried to use those bits.

Hi,

*On User Accessible FPCSR*

As per the spec FPCSR should not be accessible in user space. But...

I am currently working on the OpenRISC port for glibc, and at first I was
planning for FPU support but this was one thing that slowed me down.

For that reason I proposed an architecture change to allow setting fpcsr in user
space, it seems that is allowed by almost all other architectures:

 https://openrisc.io/proposals/p17-user-mode-fpcsr

I think I could also simulate it in the kernel by catching the mtspr failure and
then performing it on behalf of the user if its for MTSPR.

At the moment I am going with softfpu until I can spend time on sorting out the
FPCSR issue.

*On QEMU*

When I started to develop the glibc FPU code, I put a patch into qemu to allow
for using mtspr and mfspr in user space:

 branch:
  https://github.com/stffrdhrn/qemu/commits/or1k-glibc

 commit:
   https://github.com/stffrdhrn/qemu/commit/dfa5331bf43f71535847c585a6b3f5779a422b13

User space access it not allowed as per trans_l_mfspr, trans_l_mfspr.  I did not
post this upstream as it's not as per spec.

I hope it helps a bit.

-Stafford