From: Thomas Huth <thuth@redhat.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: Janosch Frank <frankja@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, Richard Henderson <rth@twiddle.net>,
Ilya Leoshkevich <iii@linux.ibm.com>
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:30:12 +0200 [thread overview]
Message-ID: <701fa06a-35e7-8903-5d07-125afb11938c@redhat.com> (raw)
In-Reply-To: <c9d4ee70-5819-722f-f404-697622ee5ce5@redhat.com>
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
next prev parent reply other threads:[~2019-08-19 13:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-05 15:29 [Qemu-devel] [PATCH-for-4.2 v1 0/9] s390x: MMU changes and extensions David Hildenbrand
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 1/9] s390x/mmu: Better ASC selection in s390_cpu_get_phys_page_debug() David Hildenbrand
2019-08-08 12:57 ` Cornelia Huck
2019-08-08 13:02 ` David Hildenbrand
2019-08-12 7:12 ` Thomas Huth
2019-08-12 7:52 ` David Hildenbrand
2019-08-12 13:40 ` Cornelia Huck
2019-08-12 13:45 ` David Hildenbrand
2019-08-12 13:58 ` Cornelia Huck
2019-08-12 14:14 ` David Hildenbrand
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 2/9] s390x/tcg: Rework MMU selection for instruction fetches David Hildenbrand
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 3/9] s390x/mmu: DAT translation rewrite David Hildenbrand
2019-08-12 7:20 ` Thomas Huth
2019-08-12 7:43 ` David Hildenbrand
2019-08-12 8:04 ` David Hildenbrand
2019-08-19 11:40 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-08-19 11:58 ` David Hildenbrand
2019-08-19 12:00 ` Thomas Huth
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 4/9] s390x/mmu: Add EDAT2 translation support David Hildenbrand
2019-08-19 12:01 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 5/9] s390x/mmu: Implement access-exception-fetch/store-indication facility David Hildenbrand
2019-08-19 12:16 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-08-19 12:22 ` Thomas Huth
2019-08-19 12:26 ` David Hildenbrand
2019-08-19 12:30 ` Thomas Huth [this message]
2019-08-19 12:35 ` David Hildenbrand
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 6/9] s390x/mmu: Implement enhanced suppression-on-protection facility 2 David Hildenbrand
2019-08-19 14:58 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 7/9] s390x/mmu: Implement Instruction-Execution-Protection Facility David Hildenbrand
2019-08-19 15:03 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 8/9] s390x/cpumodel: Prepare for changes of QEMU model David Hildenbrand
2019-08-13 16:02 ` Cornelia Huck
2019-08-19 15:07 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-08-05 15:29 ` [Qemu-devel] [PATCH-for-4.2 v1 9/9] s390x/cpumodel: Add new TCG features to QEMU cpu model David Hildenbrand
2019-08-13 16:07 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=701fa06a-35e7-8903-5d07-125afb11938c@redhat.com \
--to=thuth@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).