All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org
Cc: "Jason J . Herne" <jjherne@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, Claudio Imbrenda <imbrenda@linux.ibm.com>
Subject: Re: [PATCH v1 03/12] s390x/tcg: convert real to absolute address for RRBE, SSKE and ISKE
Date: Fri, 06 Aug 2021 13:25:33 +0200	[thread overview]
Message-ID: <8735rmzufm.fsf@redhat.com> (raw)
In-Reply-To: <efd67ce2-aaff-9887-c318-f184290f2d0a@redhat.com>

On Fri, Aug 06 2021, David Hildenbrand <david@redhat.com> wrote:

> On 06.08.21 09:11, Thomas Huth wrote:
>> On 06/08/2021 08.52, David Hildenbrand wrote:
>>>>
>>>> According to the PoP:
>>>>
>>>> "When the enhanced-DAT facility 1 is not installed, or
>>>>     when the facility is installed but the multiple-block
>>>>     control is zero, general register R 2 contains a real
>>>>     address. When the enhanced-DAT facility 1 is
>>>>     installed and the multiple-block control is one, gen-
>>>>     eral register R 2 contains an absolute address."
>>>>
>>>> Don't we have to take that into consideration here, too?
>>>
>>> We don't support EDAT1 a.k.a. huge pages yet. If we ever do, we have to
>>> further extend this code.
>> 
>> Ok, then maybe add a comment or assert() to make sure that we don't forget?
>
> Well, we'll need modifications and extensions all over the place to 
> support EDAT1, so I'm not sure this will really help ... we'll have to 
> carefully scan the PoP either way.

Something like
/* always real address, as long as we don't implement EDAT1 */
would still be useful, I think.



  reply	other threads:[~2021-08-06 11:26 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 15:27 [PATCH v1 00/12] s390x: skey related fixes, cleanups, and memory device preparations David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 01/12] s390x/tcg: wrap address for RRBE David Hildenbrand
2021-08-06  5:39   ` Thomas Huth
2021-08-05 15:27 ` [PATCH v1 02/12] s390x/tcg: fix ignoring bit 63 when setting the storage key in SSKE David Hildenbrand
2021-08-06  6:19   ` Thomas Huth
2021-08-06  6:25     ` Thomas Huth
2021-08-06  6:31       ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 03/12] s390x/tcg: convert real to absolute address for RRBE, SSKE and ISKE David Hildenbrand
2021-08-06  6:50   ` Thomas Huth
2021-08-06  6:52     ` David Hildenbrand
2021-08-06  7:11       ` Thomas Huth
2021-08-06  7:17         ` David Hildenbrand
2021-08-06 11:25           ` Cornelia Huck [this message]
2021-08-06 11:32             ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 04/12] s390x/tcg: check for addressing exceptions for " David Hildenbrand
2021-08-05 17:33   ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 05/12] s390x/mmu_helper: no need to pass access type to mmu_translate_asce() David Hildenbrand
2021-08-06  7:30   ` Thomas Huth
2021-08-06  7:34     ` David Hildenbrand
2021-08-06  7:36       ` Thomas Huth
2021-08-06  7:36         ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 06/12] s390x/mmu_helper: fixup mmu_translate() documentation David Hildenbrand
2021-08-06  7:32   ` Thomas Huth
2021-08-05 15:27 ` [PATCH v1 07/12] s390x/mmu_helper: move address validation into mmu_translate*() David Hildenbrand
2021-08-06  8:18   ` Thomas Huth
2021-08-06  8:20     ` David Hildenbrand
2021-08-06  8:22       ` Thomas Huth
2021-08-06  8:23         ` David Hildenbrand
2021-08-06  8:24           ` Thomas Huth
2021-08-06  8:20   ` Thomas Huth
2021-08-05 15:28 ` [PATCH v1 08/12] s390x/mmu_helper: avoid setting the storage key if nothing changed David Hildenbrand
2021-08-06  8:24   ` Thomas Huth
2021-08-05 15:28 ` [PATCH v1 09/12] hw/s390x/s390-skeys: use memory mapping to detect which storage keys to migrate David Hildenbrand
2021-08-06  8:47   ` Thomas Huth
2021-08-05 15:28 ` [PATCH v1 10/12] hw/s390x/s390-skeys: use memory mapping to detect which storage keys to dump David Hildenbrand
2021-08-06  8:51   ` Thomas Huth
2021-08-05 15:28 ` [PATCH v1 11/12] hw/s390x/s390-skeys: check if an address is valid before dumping the key David Hildenbrand
2021-08-06  8:53   ` Thomas Huth
2021-08-06  8:54     ` David Hildenbrand
2021-08-05 15:28 ` [PATCH v1 12/12] hw/s390x/s390-skeys: lazy storage key enablement under TCG David Hildenbrand
2021-08-06  9:42   ` Thomas Huth
2021-08-06 13:18     ` David Hildenbrand
2021-08-06 13:52       ` Thomas Huth
2021-08-11  8:43         ` David Hildenbrand
2021-08-06 14:13       ` Cornelia Huck
2021-08-06 14:17         ` Thomas Huth

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=8735rmzufm.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /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.