qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [qemu-s390x] [PATCH-for-4.2 v1 5/9] s390x/mmu: Implemen


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

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
> 


-- 

Thanks,

David / dhildenb



reply via email to

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