[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH-for-4.2 v1 5/9] s390x/mmu: Implement access-exce

From: Thomas Huth
Subject: Re: [qemu-s390x] [PATCH-for-4.2 v1 5/9] s390x/mmu: Implement access-exception-fetch/store-indication facility
Date: Mon, 19 Aug 2019 14:30:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]