From: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
To: qemu-s390x@nongnu.org,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>
Cc: Janis Schoetterl-Glausch <scgl@linux.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
David Hildenbrand <david@redhat.com>,
Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>
Subject: [PATCH 2/2] target/s390x: kvm: Honor storage keys during emulation
Date: Fri, 6 May 2022 17:39:56 +0200 [thread overview]
Message-ID: <20220506153956.2217601-3-scgl@linux.ibm.com> (raw)
In-Reply-To: <20220506153956.2217601-1-scgl@linux.ibm.com>
Storage key controlled protection is currently not honored when
emulating instructions.
If available, enable key protection for the MEM_OP ioctl, thereby
enabling it for the s390_cpu_virt_mem_* functions, when using kvm.
As a result, the emulation of the following instructions honors storage
keys:
* CLP
The Synch I/O CLP command would need special handling in order
to support storage keys, but is currently not supported.
* CHSC
Performing commands asynchronously would require special
handling, but commands are currently always synchronous.
* STSI
* TSCH
Must (and does) not change channel if terminated due to
protection.
* MSCH
Suppressed on protection, works because fetching instruction.
* SSCH
Suppressed on protection, works because fetching instruction.
* STSCH
* STCRW
Suppressed on protection, this works because no partial store is
possible, because the operand cannot span multiple pages.
* PCISTB
* MPCIFC
* STPCIFC
Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
---
target/s390x/kvm/kvm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
index 53098bf541..7bd8db0e7b 100644
--- a/target/s390x/kvm/kvm.c
+++ b/target/s390x/kvm/kvm.c
@@ -151,12 +151,15 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
static int cap_sync_regs;
static int cap_async_pf;
static int cap_mem_op;
+static int cap_mem_op_extension;
static int cap_s390_irq;
static int cap_ri;
static int cap_hpage_1m;
static int cap_vcpu_resets;
static int cap_protected;
+static bool mem_op_storage_key_support;
+
static int active_cmma;
static int kvm_s390_query_mem_limit(uint64_t *memory_limit)
@@ -354,6 +357,8 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
cap_sync_regs = kvm_check_extension(s, KVM_CAP_SYNC_REGS);
cap_async_pf = kvm_check_extension(s, KVM_CAP_ASYNC_PF);
cap_mem_op = kvm_check_extension(s, KVM_CAP_S390_MEM_OP);
+ cap_mem_op_extension = kvm_check_extension(s, KVM_CAP_S390_MEM_OP_EXTENSION);
+ mem_op_storage_key_support = cap_mem_op_extension > 0;
cap_s390_irq = kvm_check_extension(s, KVM_CAP_S390_INJECT_IRQ);
cap_vcpu_resets = kvm_check_extension(s, KVM_CAP_S390_VCPU_RESETS);
cap_protected = kvm_check_extension(s, KVM_CAP_S390_PROTECTED);
@@ -842,6 +847,7 @@ int kvm_s390_mem_op(S390CPU *cpu, vaddr addr, uint8_t ar, void *hostbuf,
: KVM_S390_MEMOP_LOGICAL_READ,
.buf = (uint64_t)hostbuf,
.ar = ar,
+ .key = (cpu->env.psw.mask & PSW_MASK_KEY) >> PSW_SHIFT_KEY,
};
int ret;
@@ -851,6 +857,9 @@ int kvm_s390_mem_op(S390CPU *cpu, vaddr addr, uint8_t ar, void *hostbuf,
if (!hostbuf) {
mem_op.flags |= KVM_S390_MEMOP_F_CHECK_ONLY;
}
+ if (mem_op_storage_key_support) {
+ mem_op.flags |= KVM_S390_MEMOP_F_SKEY_PROTECTION;
+ }
ret = kvm_vcpu_ioctl(CPU(cpu), KVM_S390_MEM_OP, &mem_op);
if (ret < 0) {
--
2.32.0
next prev parent reply other threads:[~2022-05-06 15:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-06 15:39 [PATCH 0/2] s390x: kvm: Honor storage keys during emulation Janis Schoetterl-Glausch
2022-05-06 15:39 ` [PATCH 1/2] Pull in MEMOP changes in linux-headers Janis Schoetterl-Glausch
2022-05-06 15:39 ` Janis Schoetterl-Glausch [this message]
2022-05-19 10:05 ` [PATCH 2/2] target/s390x: kvm: Honor storage keys during emulation Thomas Huth
2022-05-19 13:53 ` Janis Schoetterl-Glausch
2022-05-24 10:43 ` Thomas Huth
2022-05-24 11:10 ` Christian Borntraeger
2022-05-24 11:21 ` Thomas Huth
2022-05-24 11:52 ` Janis Schoetterl-Glausch
2022-05-25 9:00 ` Thomas Huth
2022-05-24 16:08 ` Halil Pasic
2022-05-09 8:06 ` [PATCH 0/2] s390x: " Cornelia Huck
2022-05-10 13:32 ` Janis Schoetterl-Glausch
2022-05-10 13:43 ` Cornelia Huck
2022-05-12 8:52 ` 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=20220506153956.2217601-3-scgl@linux.ibm.com \
--to=scgl@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.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.