Skip to contentSkip to conversation

target/s390x: addressing exceptions are suppressing

PATCH Applied David Hildenbrand 3 participants 3 messages May 29, 2017 – Jun 4, 2017

lore
Share & tools
lore

David Hildenbrand

author
#0 lore raw

PATCH 1/1 target/s390x: addressing exceptions are suppressing

We have to make the address in the old PSW point at the next instruction, as addressing exceptions are suppressing and not nullifying.

I assume that there are a lot of other broken cases (as most instructions we care about are suppressing) - all trigger_pgm_exception() specifying and explicit number or ILEN_LATER look suspicious, however this is another story that might require bigger changes (and I have to understand when the address might already have been incremented first).

This is needed to make an upcoming kvm-unit-test work.

Signed-off-by David Hildenbrand <[email protected]>
---
 target/s390x/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
target/s390x/helper.c +1 -1
index 9978490..c09e391 100644
@@ -204,7 +204,7 @@ int s390_cpu_handle_mmu_fault(CPUState *cs, vaddr orig_vaddr,
     if (raddr > ram_size) {
         DPRINTF("%s: raddr %" PRIx64 " > ram_size %" PRIx64 "\n", __func__,
                 (uint64_t)raddr, (uint64_t)ram_size);
-        trigger_pgm_exception(env, PGM_ADDRESSING, ILEN_LATER);
+        trigger_pgm_exception(env, PGM_ADDRESSING, ILEN_LATER_INC);
         return 1;
     }
Signature · 1 line
2.9.3
Reviewed-by on v1 1/1
#1 lore raw
Quoted 3 lines · David Hildenbrand

We have to make the address in the old PSW point at the next instruction, as addressing exceptions are suppressing and not nullifying.

According to "Figure 6-1. Interruption Action" in the PoP, they could also be terminating ... but anyway, not nullifying, so the PSW should be increased afterwards. So:

Reviewed-by Thomas Huth <[email protected]>
Quoted 27 lines

I assume that there are a lot of other broken cases (as most instructions we care about are suppressing) - all trigger_pgm_exception() specifying and explicit number or ILEN_LATER look suspicious, however this is another story that might require bigger changes (and I have to understand when the address might already have been incremented first).

This is needed to make an upcoming kvm-unit-test work.

Signed-off-by David Hildenbrand <[email protected]>
---
 target/s390x/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
target/s390x/helper.c +1 -1
index 9978490..c09e391 100644
@@ -204,7 +204,7 @@ int s390_cpu_handle_mmu_fault(CPUState *cs, vaddr orig_vaddr,
     if (raddr > ram_size) {
         DPRINTF("%s: raddr %" PRIx64 " > ram_size %" PRIx64 "\n", __func__,
                 (uint64_t)raddr, (uint64_t)ram_size);
-        trigger_pgm_exception(env, PGM_ADDRESSING, ILEN_LATER);
+        trigger_pgm_exception(env, PGM_ADDRESSING, ILEN_LATER_INC);
         return 1;
     }
Applied
#2 lore raw
In reply to David Hildenbrand
Quoted 10 lines · David Hildenbrand

We have to make the address in the old PSW point at the next instruction, as addressing exceptions are suppressing and not nullifying.

I assume that there are a lot of other broken cases (as most instructions we care about are suppressing) - all trigger_pgm_exception() specifying and explicit number or ILEN_LATER look suspicious, however this is another story that might require bigger changes (and I have to understand when the address might already have been incremented first).

Quoted 6 lines

This is needed to make an upcoming kvm-unit-test work.

Signed-off-by David Hildenbrand<[email protected]>
---
  target/s390x/helper.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

r~