From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Jason J . Herne" <jjherne@linux.ibm.com>,
Thomas Huth <thuth@redhat.com>,
Janosch Frank <frankja@linux.ibm.com>,
David Hildenbrand <david@redhat.com>,
Cornelia Huck <cohuck@redhat.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: [PATCH v3 02/13] s390x/tcg: fix ignoring bit 63 when setting the storage key in SSKE
Date: Fri, 3 Sep 2021 17:55:03 +0200 [thread overview]
Message-ID: <20210903155514.44772-3-david@redhat.com> (raw)
In-Reply-To: <20210903155514.44772-1-david@redhat.com>
Right now we could set an 8-bit storage key via SSKE and retrieve it
again via ISKE, which is against the architecture description:
SSKE:
"
The new seven-bit storage-key value, or selected bits
thereof, is obtained from bit positions 56-62 of gen-
eral register R 1 . The contents of bit positions 0-55
and 63 of the register are ignored.
"
ISKE:
"
The seven-bit storage key is inserted in bit positions
56-62 of general register R 1 , and bit 63 is set to zero.
"
Let's properly ignore bit 63 to create the correct seven-bit storage key.
Signed-off-by: David Hildenbrand <david@redhat.com>
---
target/s390x/tcg/mem_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/s390x/tcg/mem_helper.c b/target/s390x/tcg/mem_helper.c
index e0befd0f03..3c0820dd74 100644
--- a/target/s390x/tcg/mem_helper.c
+++ b/target/s390x/tcg/mem_helper.c
@@ -2210,7 +2210,7 @@ void HELPER(sske)(CPUS390XState *env, uint64_t r1, uint64_t r2)
skeyclass = S390_SKEYS_GET_CLASS(ss);
}
- key = (uint8_t) r1;
+ key = r1 & 0xfe;
skeyclass->set_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
/*
* As we can only flush by virtual address and not all the entries
--
2.31.1
next prev parent reply other threads:[~2021-09-03 15:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-03 15:55 [PATCH v3 00/13] s390x: skey related fixes, cleanups, and memory device preparations David Hildenbrand
2021-09-03 15:55 ` [PATCH v3 01/13] s390x/tcg: wrap address for RRBE David Hildenbrand
2021-09-03 15:55 ` David Hildenbrand [this message]
2021-09-06 9:57 ` [PATCH v3 02/13] s390x/tcg: fix ignoring bit 63 when setting the storage key in SSKE Thomas Huth
2021-09-03 15:55 ` [PATCH v3 03/13] s390x/tcg: convert real to absolute address for RRBE, SSKE and ISKE David Hildenbrand
2021-09-06 10:01 ` Thomas Huth
2021-09-03 15:55 ` [PATCH v3 04/13] s390x/tcg: check for addressing exceptions " David Hildenbrand
2021-09-06 10:06 ` Thomas Huth
2021-09-03 15:55 ` [PATCH v3 05/13] s390x/mmu_helper: no need to pass access type to mmu_translate_asce() David Hildenbrand
2021-09-03 15:55 ` [PATCH v3 06/13] s390x/mmu_helper: fixup mmu_translate() documentation David Hildenbrand
2021-09-03 15:55 ` [PATCH v3 07/13] s390x/mmu_helper: move address validation into mmu_translate*() David Hildenbrand
2021-09-03 15:55 ` [PATCH v3 08/13] s390x/mmu_helper: avoid setting the storage key if nothing changed David Hildenbrand
2021-09-03 15:55 ` [PATCH v3 09/13] hw/s390x/s390-skeys: use memory mapping to detect which storage keys to migrate David Hildenbrand
2021-09-03 15:55 ` [PATCH v3 10/13] hw/s390x/s390-skeys: use memory mapping to detect which storage keys to dump David Hildenbrand
2021-09-03 15:55 ` [PATCH v3 11/13] hw/s390x/s390-skeys: check if an address is valid before dumping the key David Hildenbrand
2021-09-06 10:07 ` Thomas Huth
2021-09-03 15:55 ` [PATCH v3 12/13] hw/s390x/s390-skeys: rename skeys_enabled to skeys_are_enabled David Hildenbrand
2021-09-06 10:03 ` Thomas Huth
2021-09-03 15:55 ` [PATCH v3 13/13] hw/s390x/s390-skeys: lazy storage key enablement under TCG David Hildenbrand
2021-09-06 10:14 ` Thomas Huth
2021-09-07 7:44 ` [PATCH v3 00/13] s390x: skey related fixes, cleanups, and memory device preparations 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=20210903155514.44772-3-david@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@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 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).