Re: [PATCH] target/hppa: mask upper iaoq bits when returning to narrow mode

[Sven Schnelle]

Richard Henderson <richard.henderson@linaro.org> writes:

> On 4/1/24 04:52, Sven Schnelle wrote:
>> For unknown reasons, Java 1.5 on 64-bit HP-UX 11.11 does signed
>> computation of the new IAOQ value in the signal handler. In the
>> current code these bits are not masked when returning to narrow
>> mode, causing java to crash.
>> Signed-off-by: Sven Schnelle <svens@stackframe.org>
>> ---
>>   target/hppa/sys_helper.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>> diff --git a/target/hppa/sys_helper.c b/target/hppa/sys_helper.c
>> index 208e51c086..3bbc2da71b 100644
>> --- a/target/hppa/sys_helper.c
>> +++ b/target/hppa/sys_helper.c
>> @@ -83,6 +83,10 @@ void HELPER(rfi)(CPUHPPAState *env)
>>       env->iaoq_f = env->cr[CR_IIAOQ];
>>       env->iaoq_b = env->cr_back[1];
>>   +    if (!(env->cr[CR_IPSW] & PSW_W)) {
>> +        env->iaoq_f &= 0xffffffff;
>> +        env->iaoq_b &= 0xffffffff;
>> +    }
>
> This shouldn't be needed, because we are already masking these bits
> later, in cpu_get_tb_cpu_state.  But I do have some cleanups in this
> area, and perhaps one of them matters.

Ouch. Appologies, i removed that masking to make 64 bit work, but forgot
about that. Sorry. I tried your branch, but i'm not able to boot 64 bit HP-UX
(it wasn't working before without additional changes, so your branch
doesn't break it). However, i would like to get your oppinion before
debugging. The code is:

IN: 
0xef4680000002c18:   20 20 08 01   ldil L%-40000000,r1
0xef4680000002c1c:   e4 20 e0 08   be,l 4(sr7,r1),sr0,r31
0xef4680000002c20:   34 16 00 72   ldi 39,r22

IA_F 0ef46800:0000000000002c23 (0ef4680000002c23)
IA_B 01e27c00:ffffffffc0000007 (01e27c00c0000007)
PSW  000000000004000f CB   0000000000000000 ---------C----QPDI
GR00 0000000000000000 GR01 ffffffffc0000000 GR02 0000000000002ac3 GR03 
000000007a000000
GR04 0000000000000002 GR05 000000007a000034 GR06 000000007a000040 GR07 
000000007a000050
GR08 000000007a0000e0 GR09 8000000040001000 GR10 0000000000000003 GR11 
0000000000000006
GR12 00000000001ecee8 GR13 00000000ffffffff GR14 0000000000000801 GR15 
0000000000000006
GR16 80000000400020c0 GR17 000000000001e720 GR18 0000000000000008 GR19 
0000000000000000
GR20 000000000ef46800 GR21 000000007a000060 GR22 0000000000000000 GR23 
000000007a000050
GR24 0000000000000000 GR25 0000000000000000 GR26 000000007a0020f0 GR27 
0000000040008410
GR28 0000000000000002 GR29 0000000000000000 GR30 000000007a002160 GR31 
0000000000002c27
RC   000000007fffffff CR1  0000000000000000 CR2  0000000000000000 CR3  
0000000000000000
CR4  0000000000000000 CR5  0000000000000000 CR6  0000000000000002 CR7  
fffffffffffb0000
PID1 000000000000256f PID2 0000000000007306 CCR  00000000000000c0 SAR  
0000000000000004
PID3 0000000000000000 PID4 0000000000000000 IVA  000000000002a000 EIEM 
ffffffffffffffff
ITMR 00000005d637f804 ISQF 000000000ef46800 IOQF 0000000000002aab IIR  
000000006bc23fd9
ISR  0000000004d0d000 IOR  400000007a0020cc IPSW 000000000004000f EIRR 
0000000000000000
TR0  0000000000abfe68 TR1  000000000465d1d6 TR2  0000000000000002 TR3  
0000000000000000
TR4  0000000000000000 TR5  00000001757973bb TR6  00000000000021eb TR7  
000000007a0020e0
ISQB 000000000ef46800 IOQB 0000000000002aaf
SR00 0ef46800 SR01 00000000 SR02 00000000 SR03 00000000
SR04 0ef46800 SR05 04d0d000 SR06 01e27c00 SR07 01e27c00

INT   3529: instruction tlb miss fault @ 0000000001e27c00:ffffffffc0000007 for 
0000000001e27c00:40000000c0000004
INT   3530: instruction tlb miss fault @ 0000000000000000:ffffffffc0000007 for 
0000000000000000:40000000c0000004
INT   3531: external interrupt @ 0000000000000000:ffffffffc0000007 for 
0000000000000000:40000000c0000004
INT   3532: instruction tlb miss fault @ 0000000000000000:ffffffffc0000007 for 
0000000000000000:40000000c0000004
INT   3533: external interrupt @ 0000000000000000:ffffffffc0000007 for 
0000000000000000:40000000c0000004

So the PSW indicates narrow mode, but IAOQ seems to contain all the
ffff... bits. Also interesting is that the second TLB miss (INT 3530)
misses the Space ID.

Any thoughts? Otherwise i need to investigate and make a wrong patch
again :-)

The only patch i have on top which touches target/hppa is the space id
hashing mask patch:

diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index 66cae795bd..b35c7fa688 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -311,12 +311,13 @@ static inline int HPPA_BTLB_ENTRIES(CPUHPPAState *env)

 void hppa_translate_init(void);

+#define HPPA_GVA_OFFSET_MASK64 0x301fffffffffffff
 #define CPU_RESOLVING_TYPE TYPE_HPPA_CPU

 static inline uint64_t gva_offset_mask(target_ulong psw)
 {
     return (psw & PSW_W
-            ? MAKE_64BIT_MASK(0, 62)
+            ? HPPA_GVA_OFFSET_MASK64
             : MAKE_64BIT_MASK(0, 32));
 }

But that hoppefully isn't causing the issue here.