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;
+ }
/*
* For pa2.0, IIASQ is the top bits of the virtual address.
* To recreate the space identifier, remove the offset bits.
--
2.43.2On 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.
Please try
https://gitlab.com/rth7680/qemu/-/commit/d06e0303595a63565593ab2a5d42f312135b9ded
r~
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.
On 4/1/24 10:39, Sven Schnelle wrote:
> 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.
I believe that the IAOQ *should* contain all of the bits. The bits should only be
discarded when we form the GVA -- exactly like "ldb 0(r2)", where r2 contains all of the
offset bits. In particular, I believe that "b,l .+8,r2" should copy all of those bits to
r2 from IAOQ_Back+4 and the fact that mainline crops those bits is a bug.
> Also interesting is that the second TLB miss (INT 3530)
> misses the Space ID.
That is a bit curious, yes.
> 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:
Ok. I do have an hppa 11.11 iso -- for clarity, what is your command-line?
r~
Richard Henderson <richard.henderson@linaro.org> writes: > On 4/1/24 10:39, Sven Schnelle wrote: >> Richard Henderson <richard.henderson@linaro.org> writes: >>>> 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> >> 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. > > I believe that the IAOQ *should* contain all of the bits. The bits > should only be discarded when we form the GVA -- exactly like "ldb > 0(r2)", where r2 contains all of the offset bits. In particular, I > believe that "b,l .+8,r2" should copy all of those bits to r2 from > IAOQ_Back+4 and the fact that mainline crops those bits is a bug. > > >> Also interesting is that the second TLB miss (INT 3530) >> misses the Space ID. > > That is a bit curious, yes. > >> 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: > > Ok. I do have an hppa 11.11 iso -- for clarity, what is your command-line? I'm using: ./build/qemu-system-hppa -M C3700 -m 1024 -cdrom /home/svens/parisc/hpux/11.11/HP-UX 11.11 (2004-12) - TCOE - Core OS, Install and Recovery - DVD.iso -bios /home/svens/seabios-hppa/out-64/hppa-firmware64.img -nographic -hda /home/svens/parisc/hpux1111.img -boot d The qemu i'm using is: https://github.com/svenschnelle/qemu/tree/devel You also need a special seabios-hppa version, because a special console driver is needed: https://github.com/hdeller/seabios-hppa/tree/devel
Sven Schnelle <svens@stackframe.org> writes:
> 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 :-)
This seems to be caused by IIAOQ's containing the upper bits. With the
patch below i'm able to boot. Not sure whether it's correct though.
diff --git a/target/hppa/int_helper.c b/target/hppa/int_helper.c
index 58c13d3e61..f7c4cca8f1 100644
--- a/target/hppa/int_helper.c
+++ b/target/hppa/int_helper.c
@@ -123,8 +123,14 @@ void hppa_cpu_do_interrupt(CPUState *cs)
env->cr[CR_IIASQ] = 0;
env->cr_back[0] = 0;
}
- env->cr[CR_IIAOQ] = env->iaoq_f;
- env->cr_back[1] = env->iaoq_b;
+ if (old_psw & PSW_W) {
+ env->cr[CR_IIAOQ] = env->iaoq_f;
+ env->cr_back[1] = env->iaoq_b;
+ } else {
+ env->cr[CR_IIAOQ] = (env->iaoq_f & 0xffffffff);
+ env->cr_back[1] = env->iaoq_b & 0xffffffff;
+ }
+
Sven Schnelle <svens@stackframe.org> writes:
> Sven Schnelle <svens@stackframe.org> writes:
>
>> 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.
>> Any thoughts? Otherwise i need to investigate and make a wrong patch
>> again :-)
>
> This seems to be caused by IIAOQ's containing the upper bits. With the
> patch below i'm able to boot. Not sure whether it's correct though.
>
> diff --git a/target/hppa/int_helper.c b/target/hppa/int_helper.c
> index 58c13d3e61..f7c4cca8f1 100644
> --- a/target/hppa/int_helper.c
> +++ b/target/hppa/int_helper.c
> @@ -123,8 +123,14 @@ void hppa_cpu_do_interrupt(CPUState *cs)
> env->cr[CR_IIASQ] = 0;
> env->cr_back[0] = 0;
> }
> - env->cr[CR_IIAOQ] = env->iaoq_f;
> - env->cr_back[1] = env->iaoq_b;
> + if (old_psw & PSW_W) {
> + env->cr[CR_IIAOQ] = env->iaoq_f;
> + env->cr_back[1] = env->iaoq_b;
> + } else {
> + env->cr[CR_IIAOQ] = (env->iaoq_f & 0xffffffff);
> + env->cr_back[1] = env->iaoq_b & 0xffffffff;
> + }
> +
I guess the interesting question where should these bits get masked out
- i would assume that this place is to late, and it should happen
earlier in trans_be/when the iaoq value is copied. On the other hand
you had one commit that removed the masking in copy_iaoq_entry()...
On 4/1/24 10:56, Sven Schnelle wrote:
>> This seems to be caused by IIAOQ's containing the upper bits. With the
>> patch below i'm able to boot. Not sure whether it's correct though.
>>
>> diff --git a/target/hppa/int_helper.c b/target/hppa/int_helper.c
>> index 58c13d3e61..f7c4cca8f1 100644
>> --- a/target/hppa/int_helper.c
>> +++ b/target/hppa/int_helper.c
>> @@ -123,8 +123,14 @@ void hppa_cpu_do_interrupt(CPUState *cs)
>> env->cr[CR_IIASQ] = 0;
>> env->cr_back[0] = 0;
>> }
>> - env->cr[CR_IIAOQ] = env->iaoq_f;
>> - env->cr_back[1] = env->iaoq_b;
>> + if (old_psw & PSW_W) {
>> + env->cr[CR_IIAOQ] = env->iaoq_f;
>> + env->cr_back[1] = env->iaoq_b;
>> + } else {
>> + env->cr[CR_IIAOQ] = (env->iaoq_f & 0xffffffff);
>> + env->cr_back[1] = env->iaoq_b & 0xffffffff;
>> + }
>> +
>
> I guess the interesting question where should these bits get masked out
> - i would assume that this place is to late, and it should happen
> earlier in trans_be/when the iaoq value is copied. On the other hand
> you had one commit that removed the masking in copy_iaoq_entry()...
I would have said this masking should not happen at all.
r~
© 2016 - 2024 Red Hat, Inc.