All of lore.kernel.org
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH v2 6/7] s390x/mmu: DAT table definition overhaul
Date: Thu, 26 Sep 2019 09:52:51 +0200	[thread overview]
Message-ID: <a23494c5-be2e-448d-e96c-864c7841ec29@redhat.com> (raw)
In-Reply-To: <dee25e68-43f2-f6b5-ce2f-f76112b33f5d@redhat.com>

On 26/09/2019 09.38, David Hildenbrand wrote:
> On 26.09.19 09:35, Thomas Huth wrote:
>> On 25/09/2019 14.52, David Hildenbrand wrote:
>>> Let's use consitent names for the region/section/page table entries and
>>> for the macros to extract relevant parts from virtual address. Make them
>>> match the definitions in the PoP - e.g., how the televant bits are actually
>>
>> s/televant/relevant/
>>
>>> called.
>>>
>>> Introduce defines for all bits declared in the PoP. This will come in
>>> handy in follow-up patches.
>>>
>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>> ---
>>>  target/s390x/cpu.h        | 77 +++++++++++++++++++++++++++++----------
>>>  target/s390x/mem_helper.c | 12 +++---
>>>  target/s390x/mmu_helper.c | 37 ++++++++++---------
>>>  3 files changed, 83 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
>>> index 163dae13d7..e74a809257 100644
>>> --- a/target/s390x/cpu.h
>>> +++ b/target/s390x/cpu.h
>>> @@ -558,26 +558,63 @@ QEMU_BUILD_BUG_ON(sizeof(SysIB) != 4096);
>>>  #define ASCE_TYPE_SEGMENT     0x00        /* segment table type               */
>>>  #define ASCE_TABLE_LENGTH     0x03        /* region table length              */
>>>  
>>> -#define REGION_ENTRY_ORIGIN   (~0xfffULL) /* region/segment table origin    */
>>> -#define REGION_ENTRY_RO       0x200       /* region/segment protection bit  */
>>> -#define REGION_ENTRY_TF       0xc0        /* region/segment table offset    */
>>> -#define REGION_ENTRY_INV      0x20        /* invalid region table entry     */
>>> -#define REGION_ENTRY_TYPE_MASK 0x0c       /* region/segment table type mask */
>>> -#define REGION_ENTRY_TYPE_R1  0x0c        /* region first table type        */
>>> -#define REGION_ENTRY_TYPE_R2  0x08        /* region second table type       */
>>> -#define REGION_ENTRY_TYPE_R3  0x04        /* region third table type        */
>>> -#define REGION_ENTRY_LENGTH   0x03        /* region third length            */
>>> -
>>> -#define SEGMENT_ENTRY_ORIGIN  (~0x7ffULL) /* segment table origin        */
>>> -#define SEGMENT_ENTRY_FC      0x400       /* format control              */
>>> -#define SEGMENT_ENTRY_RO      0x200       /* page protection bit         */
>>> -#define SEGMENT_ENTRY_INV     0x20        /* invalid segment table entry */
>>> -
>>> -#define VADDR_PX              0xff000     /* page index bits   */
>>> -
>>> -#define PAGE_RO               0x200       /* HW read-only bit  */
>>> -#define PAGE_INVALID          0x400       /* HW invalid bit    */
>>> -#define PAGE_RES0             0x800       /* bit must be zero  */
>>> +#define REGION_ENTRY_ORIGIN         0xfffffffffffff000ULL
>>> +#define REGION_ENTRY_P              0x0000000000000200ULL
>>> +#define REGION_ENTRY_TF             0x00000000000000c0ULL
>>> +#define REGION_ENTRY_I              0x0000000000000020ULL
>>> +#define REGION_ENTRY_TT             0x000000000000000cULL
>>> +#define REGION_ENTRY_TL             0x0000000000000003ULL
>>
>> Any chance that you could keep the comments after the definitions? I
>> think they are useful for people who are not 100% familiar with the DAT
>> on s390x.
> 
> I thought about that, but do we expect people that don't have a clue
> about s390x DAT and don't compare the code against the PoP to understand
> our DAT translation just by comments on defines?

I'm not sure that everybody is aware of the PoP ... maybe you could just
put a comment in front of the block a la:

/*
 * For details on the following definitions, see the "Dynamic Address
 * Translation" section in chapter 3 of the "z/Architecture Principles
 * of Operations - SA22-7832-11"
 */

?

 Thomas


  reply	other threads:[~2019-09-26  7:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 12:52 [PATCH v2 0/7] s390x/mmu: DAT translation rewrite David Hildenbrand
2019-09-25 12:52 ` [PATCH v2 1/7] s390x/mmu: Drop debug logging from MMU code David Hildenbrand
2019-09-25 13:28   ` Thomas Huth
2019-09-25 19:11   ` Richard Henderson
2019-09-25 12:52 ` [PATCH v2 2/7] s390x/mmu: Move DAT protection handling out of mmu_translate_asce() David Hildenbrand
2019-09-25 17:01   ` Thomas Huth
2019-09-25 19:14   ` Richard Henderson
2019-09-25 12:52 ` [PATCH v2 3/7] s390x/mmu: Inject DAT exceptions from a single place David Hildenbrand
2019-09-25 17:05   ` Thomas Huth
2019-09-25 19:14   ` Richard Henderson
2019-09-25 12:52 ` [PATCH v2 4/7] s390x/mmu: Inject PGM_ADDRESSING on boguous table addresses David Hildenbrand
2019-09-25 17:12   ` Thomas Huth
2019-09-25 19:25   ` Richard Henderson
2019-09-25 19:36     ` David Hildenbrand
2019-09-25 12:52 ` [PATCH v2 5/7] s390x/mmu: Use TARGET_PAGE_MASK in mmu_translate_pte() David Hildenbrand
2019-09-25 17:15   ` Thomas Huth
2019-09-25 19:26   ` Richard Henderson
2019-09-25 12:52 ` [PATCH v2 6/7] s390x/mmu: DAT table definition overhaul David Hildenbrand
2019-09-26  7:35   ` Thomas Huth
2019-09-26  7:38     ` David Hildenbrand
2019-09-26  7:52       ` Thomas Huth [this message]
2019-09-26  7:59         ` David Hildenbrand
2019-09-26  8:07           ` Thomas Huth
2019-09-25 12:52 ` [PATCH v2 7/7] s390x/mmu: Convert to non-recursive page table walk David Hildenbrand

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=a23494c5-be2e-448d-e96c-864c7841ec29@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.