Re: [Qemu-devel] Fwd: [PATCH v2.5] fixup! linux-user/sh4: Notice gUSA regions during signal delivery

[Aurelien Jarno]

On 2017-07-07 09:00, Richard Henderson wrote:
> On 07/07/2017 07:57 AM, Richard Henderson wrote:
> > +/* ??? The SH4 kernel checks for and address above 0xC000.
> > +   However, the page mappings in qemu linux-user aren't as restricted
> > +   and we wind up with the normal stack mapped above 0xF000.
> > +   That said, there is no reason why the kernel should be allowing
> > +   a gUSA region that spans 1GB.  Use a tighter check here, for what
> > +   can actually be enabled by the immediate move.  */
> 
> Additionally, I can (and should) fix the address space problem for SH4 in
> linux-user/main.c, where we have already done so for MIPS and Nios2.
> 
> See the initialization of reserved_va.

I guess it's what you have done in the "linux-user fixes for va
mapping", which renders this version 2.5 obsolete. Therefore I guess the
version 2 is the one to be used instead.

Unfortunately my knowledge of linux-user is rather limited to review
this new series.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] Fwd: [PATCH v2.5] fixup! linux-user/sh4: Notice gUSA regions during signal delivery

[Richard Henderson]

On 07/07/2017 07:57 AM, Richard Henderson wrote:

+/* ??? The SH4 kernel checks for and address above 0xC000.
+   However, the page mappings in qemu linux-user aren't as restricted
+   and we wind up with the normal stack mapped above 0xF000.
+   That said, there is no reason why the kernel should be allowing
+   a gUSA region that spans 1GB.  Use a tighter check here, for what
+   can actually be enabled by the immediate move.  */


Additionally, I can (and should) fix the address space problem for SH4 in 
linux-user/main.c, where we have already done so for MIPS and Nios2.


See the initialization of reserved_va.


r~

[Qemu-devel] Fwd: [PATCH v2.5] fixup! linux-user/sh4: Notice gUSA regions during signal delivery

[Richard Henderson]

Bah.  Should have gone to the list as well.

r~
-- Forwarded message --
From: Richard Henderson 
Date: Fri, Jul 7, 2017 at 6:38 AM
Subject: [PATCH v2.5] fixup! linux-user/sh4: Notice gUSA regions during
signal delivery
To: glaub...@physik.fu-berlin.de
Cc: laur...@vivier.eu


This fixes the signal delivery problem reported.  I'll fold this into
the patch properly for v3, but this will allow reasonable testing to
proceed in the meantime.

r~
---
 linux-user/signal.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index 8c0b851..d68bd26 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -3476,13 +3476,18 @@ static abi_ulong get_sigframe(struct
target_sigaction *ka,
translate such sequences differently in a parallel context.  */
 static void unwind_gusa(CPUSH4State *regs)
 {
-/* If the stack pointer is sufficiently negative ... */
-if ((regs->gregs[15] & 0xc000u) == 0xc000u
-/* ... and we haven't completed the sequence ... */
-&& regs->pc < regs->gregs[0]) {
+/* If the stack pointer is sufficiently negative, and we haven't
+   completed the sequence, then reset to the entry to the region.  */
+/* ??? The SH4 kernel checks for and address above 0xC000.
+   However, the page mappings in qemu linux-user aren't as restricted
+   and we wind up with the normal stack mapped above 0xF000.
+   That said, there is no reason why the kernel should be allowing
+   a gUSA region that spans 1GB.  Use a tighter check here, for what
+   can actually be enabled by the immediate move.  */
+if (regs->gregs[15] >= -128u && regs->pc < regs->gregs[0]) {
 /* Reset the PC to before the gUSA region, as computed from
-   R0 = region end, SP = -(region size), plus one more insn
-   that actually sets SP to the region size.  */
+   R0 = region end, SP = -(region size), plus one more for the
+   insn that actually initializes SP to the region size.  */
 regs->pc = regs->gregs[0] + regs->gregs[15] - 2;

 /* Reset the SP to the saved version in R1.  */
--
2.9.4