| Message ID | 20170529121228.2789-1-david@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 29.05.2017 14:12, David Hildenbrand wrote: > 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 <thuth@redhat.com> > 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 <david@redhat.com> > --- > target/s390x/helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/s390x/helper.c b/target/s390x/helper.c > index 9978490..c09e391 100644 > --- a/target/s390x/helper.c > +++ b/target/s390x/helper.c > @@ -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; > } > >
On 05/29/2017 05:12 AM, David Hildenbrand wrote: > 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<david@redhat.com> > --- > target/s390x/helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. r~
diff --git a/target/s390x/helper.c b/target/s390x/helper.c index 9978490..c09e391 100644 --- a/target/s390x/helper.c +++ b/target/s390x/helper.c @@ -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; }
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 <david@redhat.com> --- target/s390x/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)