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
next prev parent reply other threads:[~2021-09-21 20:47 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-22 3:55 [PATCH v2 00/30] linux-user: Clean up siginfo_t handling Richard Henderson
2021-08-22 3:55 ` [PATCH v2 01/30] linux-user/aarch64: Set siginfo_t addr field for SIGTRAP signals Richard Henderson
2021-08-22 3:55 ` [PATCH v2 02/30] linux-user/arm: " Richard Henderson
2021-08-22 3:55 ` [PATCH v2 03/30] linux-user/arm: Use force_sig() to deliver fpa11 emulation SIGFPE Richard Henderson
2021-08-22 3:55 ` [PATCH v2 04/30] linux-user: Zero out target_siginfo_t in force_sig() Richard Henderson
2021-08-24 16:32 ` Philippe Mathieu-Daudé
2021-08-22 3:55 ` [PATCH v2 05/30] linux-user: Provide new force_sig_fault() function Richard Henderson
2021-08-24 16:36 ` Philippe Mathieu-Daudé
2021-08-22 3:55 ` [PATCH v2 06/30] linux-user: Provide new force_sigsegv_for_addr() function Richard Henderson
2021-08-24 16:20 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 07/30] linux-user/arm: Use force_sig_fault() Richard Henderson
2021-08-24 16:38 ` Philippe Mathieu-Daudé
2021-08-22 3:55 ` [PATCH v2 08/30] linux-user/aarch64: " Richard Henderson
2021-08-24 16:39 ` Philippe Mathieu-Daudé
2021-08-22 3:55 ` [PATCH v2 09/30] linux-user/alpha: Set TRAP_UNK for bugchk and unknown gentrap Richard Henderson
2021-08-24 16:22 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 10/30] linux-user/alpha: Set FPE_FLTUNK for gentrap ROPRAND Richard Henderson
2021-08-24 16:22 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 11/30] linux-user/alpha: Use force_sig_fault, force_sigsegv_code Richard Henderson
2021-08-24 16:24 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 12/30] linux-user/cris: " Richard Henderson
2021-08-24 16:27 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 13/30] linux-user/hexagon: Use force_sigsegv_code Richard Henderson
2021-08-24 16:29 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 14/30] linux-user/hppa: Use force_sig_fault, force_sigsegv_for_addr Richard Henderson
2021-08-24 16:32 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 15/30] linux-user/hppa: Use the proper si_code for PRIV_OPR, PRIV_REG, OVERFLOW Richard Henderson
2021-08-24 16:34 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 16/30] linux-user/hppa: Set FPE_CONDTRAP for COND Richard Henderson
2021-08-24 16:37 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 17/30] linux-user/i386: Split out maybe_handle_vm86_trap Richard Henderson
2021-08-24 16:38 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 18/30] linux-user/i386: Use force_sig, force_sig_fault, force_sigsegv_for_addr Richard Henderson
2021-08-24 16:40 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 19/30] linux-user/m68k: Use " Richard Henderson
2021-08-24 16:41 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 20/30] linux-user/microblaze: " Richard Henderson
2021-08-24 16:42 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 21/30] linux-user/microblaze: Fix SIGFPE si_codes Richard Henderson
2021-08-24 16:55 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 22/30] linux-user/mips: Improve do_break Richard Henderson
2021-08-24 16:46 ` Philippe Mathieu-Daudé
2021-08-22 3:55 ` [PATCH v2 23/30] linux-user/mips: Use force_sig_fault, force_sigsegv_for_addr Richard Henderson
2021-08-24 17:04 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 24/30] linux-user/openrisc: " Richard Henderson
2021-08-24 17:17 ` Peter Maydell
2021-09-19 17:49 ` Richard Henderson
2021-09-21 20:26 ` Stafford Horne [this message]
2021-08-22 3:55 ` [PATCH v2 25/30] linux-user/ppc: " Richard Henderson
2021-08-24 17:19 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 26/30] linux-user/riscv: " Richard Henderson
2021-08-24 17:23 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 27/30] linux-user/s390x: " Richard Henderson
2021-08-24 17:23 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 28/30] linux-user/sh4: " Richard Henderson
2021-08-24 17:24 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 29/30] linux-user/sparc: " Richard Henderson
2021-08-24 17:25 ` Peter Maydell
2021-08-22 3:55 ` [PATCH v2 30/30] linux-user/xtensa: " Richard Henderson
2021-08-24 17:26 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YUo/7zXG993jbOVQ@antec \
--to=shorne@gmail.com \
--cc=laurent@vivier.eu \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).