| Message ID | 20190805152947.28536-6-david@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | s390x: MMU changes and extensions | expand |
On 8/5/19 5:29 PM, David Hildenbrand wrote: > We always have to indicate whether it is a fetch or a store for all access > exceptions. This is only missing for LAP exceptions. Do we really need this for LAP, too? If I get figure 3-5 "Enhanced Suppression-on-Protection Results" right, these bits are not set for LAP exceptions...? Do I miss something? Thomas
On 8/19/19 2:16 PM, Thomas Huth wrote: > On 8/5/19 5:29 PM, David Hildenbrand wrote: >> We always have to indicate whether it is a fetch or a store for all access >> exceptions. This is only missing for LAP exceptions. > > Do we really need this for LAP, too? If I get figure 3-5 "Enhanced > Suppression-on-Protection Results" right, these bits are not set for LAP > exceptions...? Do I miss something? I was looking at an older version of the PoP ... the table that I mean is "Figure 3-8. Enhanced Suppression-on-Protection Facility 2 Results" in SA22-7832-11. Thomas
On 19.08.19 14:22, Thomas Huth wrote: > On 8/19/19 2:16 PM, Thomas Huth wrote: >> On 8/5/19 5:29 PM, David Hildenbrand wrote: >>> We always have to indicate whether it is a fetch or a store for all access >>> exceptions. This is only missing for LAP exceptions. >> >> Do we really need this for LAP, too? If I get figure 3-5 "Enhanced >> Suppression-on-Protection Results" right, these bits are not set for LAP >> exceptions...? Do I miss something? > > I was looking at an older version of the PoP ... the table that I mean > is "Figure 3-8. Enhanced Suppression-on-Protection Facility 2 Results" > in SA22-7832-11. > > Thomas > I think that table only states that if 56==60==61==0, then we might have either KCP or LAP ("Presented if TEID details are not available" - but as we have TEID information available, we can just set 56=1 and 60=61=0 (== LAP), or am I missing something?
On 8/19/19 2:26 PM, David Hildenbrand wrote: > On 19.08.19 14:22, Thomas Huth wrote: >> On 8/19/19 2:16 PM, Thomas Huth wrote: >>> On 8/5/19 5:29 PM, David Hildenbrand wrote: >>>> We always have to indicate whether it is a fetch or a store for all access >>>> exceptions. This is only missing for LAP exceptions. >>> >>> Do we really need this for LAP, too? If I get figure 3-5 "Enhanced >>> Suppression-on-Protection Results" right, these bits are not set for LAP >>> exceptions...? Do I miss something? >> >> I was looking at an older version of the PoP ... the table that I mean >> is "Figure 3-8. Enhanced Suppression-on-Protection Facility 2 Results" >> in SA22-7832-11. >> >> Thomas >> > > I think that table only states that if 56==60==61==0, then we might have > either KCP or LAP ("Presented if TEID details are not available" - but > as we have TEID information available, we can just set 56=1 and 60=61=0 > (== LAP), or am I missing something? Oh, well, I was looking at the older version of the PoP first, and it was not specified there yet, and when I started looking the the new version, I only saw the first LAP line and stopped reading properly afterwards... of course you're right, there is another LAP line in the table where they say that the address is correclty specified. Please mentioned the "Enhanced Suppression-on-Protection Facility 2" (which introduced this new behavior) in the patch description to make this clear, then your patch is fine. Thomas
On 19.08.19 14:30, Thomas Huth wrote: > On 8/19/19 2:26 PM, David Hildenbrand wrote: >> On 19.08.19 14:22, Thomas Huth wrote: >>> On 8/19/19 2:16 PM, Thomas Huth wrote: >>>> On 8/5/19 5:29 PM, David Hildenbrand wrote: >>>>> We always have to indicate whether it is a fetch or a store for all access >>>>> exceptions. This is only missing for LAP exceptions. >>>> >>>> Do we really need this for LAP, too? If I get figure 3-5 "Enhanced >>>> Suppression-on-Protection Results" right, these bits are not set for LAP >>>> exceptions...? Do I miss something? >>> >>> I was looking at an older version of the PoP ... the table that I mean >>> is "Figure 3-8. Enhanced Suppression-on-Protection Facility 2 Results" >>> in SA22-7832-11. >>> >>> Thomas >>> >> >> I think that table only states that if 56==60==61==0, then we might have >> either KCP or LAP ("Presented if TEID details are not available" - but >> as we have TEID information available, we can just set 56=1 and 60=61=0 >> (== LAP), or am I missing something? > > Oh, well, I was looking at the older version of the PoP first, and it > was not specified there yet, and when I started looking the the new > version, I only saw the first LAP line and stopped reading properly > afterwards... of course you're right, there is another LAP line in the > table where they say that the address is correclty specified. > > Please mentioned the "Enhanced Suppression-on-Protection > Facility 2" (which introduced this new behavior) in the patch > description to make this clear, then your patch is fine. > Ah, right, that comes in the next patch. Might make sense to reshuffle both patches. Will have a look. Thanks! > Thomas >
diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c index 5c9c7d385d..f3e988e4fd 100644 --- a/target/s390x/mmu_helper.c +++ b/target/s390x/mmu_helper.c @@ -333,7 +333,7 @@ int mmu_translate(CPUS390XState *env, target_ulong vaddr, int rw, uint64_t asc, *flags |= PAGE_WRITE_INV; if (is_low_address(vaddr) && rw == MMU_DATA_STORE) { if (exc) { - trigger_access_exception(env, PGM_PROTECTION, ILEN_AUTO, 0); + trigger_access_exception(env, PGM_PROTECTION, ilen, tec); } return -EACCES; } @@ -511,6 +511,8 @@ void s390_cpu_virt_mem_handle_exc(S390CPU *cpu, uintptr_t ra) int mmu_translate_real(CPUS390XState *env, target_ulong raddr, int rw, target_ulong *addr, int *flags) { + uint64_t tec = (raddr & TARGET_PAGE_MASK) | + (rw == MMU_DATA_STORE ? FS_WRITE : FS_READ); const bool lowprot_enabled = env->cregs[0] & CR0_LOWPROT; *flags = PAGE_READ | PAGE_WRITE | PAGE_EXEC; @@ -518,7 +520,7 @@ int mmu_translate_real(CPUS390XState *env, target_ulong raddr, int rw, /* see comment in mmu_translate() how this works */ *flags |= PAGE_WRITE_INV; if (is_low_address(raddr) && rw == MMU_DATA_STORE) { - trigger_access_exception(env, PGM_PROTECTION, ILEN_AUTO, 0); + trigger_access_exception(env, PGM_PROTECTION, ILEN_AUTO, tec); return -EACCES; } }
We always have to indicate whether it is a fetch or a store for all access exceptions. This is only missing for LAP exceptions. Signed-off-by: David Hildenbrand <david@redhat.com> --- target/s390x/mmu_helper.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)