All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
To: Christian Borntraeger <borntraeger@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Janis Schoetterl-Glausch <scgl@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org
Subject: [PATCH v2 1/2] KVM: s390: Don't indicate suppression on dirtying, failing memop
Date: Mon, 25 Apr 2022 12:01:46 +0200	[thread overview]
Message-ID: <20220425100147.1755340-2-scgl@linux.ibm.com> (raw)
In-Reply-To: <20220425100147.1755340-1-scgl@linux.ibm.com>

If user space uses a memop to emulate an instruction and that
memop fails, the execution of the instruction ends.
Instruction execution can end in different ways, one of which is
suppression, which requires that the instruction execute like a no-op.
A writing memop that spans multiple pages and fails due to key
protection can modified guest memory, as a result, the likely
correct ending is termination. Therefore do not indicate a
suppressing instruction ending in this case.

Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
---
 arch/s390/kvm/gaccess.c | 47 ++++++++++++++++++++++++-----------------
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/arch/s390/kvm/gaccess.c b/arch/s390/kvm/gaccess.c
index d53a183c2005..3b1fbef82288 100644
--- a/arch/s390/kvm/gaccess.c
+++ b/arch/s390/kvm/gaccess.c
@@ -491,8 +491,8 @@ enum prot_type {
 	PROT_TYPE_IEP  = 4,
 };
 
-static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva,
-		     u8 ar, enum gacc_mode mode, enum prot_type prot)
+static int trans_exc_ending(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar,
+			    enum gacc_mode mode, enum prot_type prot, bool suppress)
 {
 	struct kvm_s390_pgm_info *pgm = &vcpu->arch.pgm;
 	struct trans_exc_code_bits *tec;
@@ -503,22 +503,24 @@ static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva,
 
 	switch (code) {
 	case PGM_PROTECTION:
-		switch (prot) {
-		case PROT_TYPE_IEP:
-			tec->b61 = 1;
-			fallthrough;
-		case PROT_TYPE_LA:
-			tec->b56 = 1;
-			break;
-		case PROT_TYPE_KEYC:
-			tec->b60 = 1;
-			break;
-		case PROT_TYPE_ALC:
-			tec->b60 = 1;
-			fallthrough;
-		case PROT_TYPE_DAT:
-			tec->b61 = 1;
-			break;
+		if (suppress) {
+			switch (prot) {
+			case PROT_TYPE_IEP:
+				tec->b61 = 1;
+				fallthrough;
+			case PROT_TYPE_LA:
+				tec->b56 = 1;
+				break;
+			case PROT_TYPE_KEYC:
+				tec->b60 = 1;
+				break;
+			case PROT_TYPE_ALC:
+				tec->b60 = 1;
+				fallthrough;
+			case PROT_TYPE_DAT:
+				tec->b61 = 1;
+				break;
+			}
 		}
 		fallthrough;
 	case PGM_ASCE_TYPE:
@@ -552,6 +554,12 @@ static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva,
 	return code;
 }
 
+static int trans_exc(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar,
+		     enum gacc_mode mode, enum prot_type prot)
+{
+	return trans_exc_ending(vcpu, code, gva, ar, mode, prot, true);
+}
+
 static int get_vcpu_asce(struct kvm_vcpu *vcpu, union asce *asce,
 			 unsigned long ga, u8 ar, enum gacc_mode mode)
 {
@@ -1110,7 +1118,8 @@ int access_guest_with_key(struct kvm_vcpu *vcpu, unsigned long ga, u8 ar,
 		ga = kvm_s390_logical_to_effective(vcpu, ga + fragment_len);
 	}
 	if (rc > 0)
-		rc = trans_exc(vcpu, rc, ga, ar, mode, prot);
+		rc = trans_exc_ending(vcpu, rc, ga, ar, mode, prot,
+				      (mode != GACC_STORE) || (idx == 0));
 out_unlock:
 	if (need_ipte_lock)
 		ipte_unlock(vcpu);
-- 
2.32.0


  reply	other threads:[~2022-04-25 10:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25 10:01 [PATCH v2 0/2] Dirtying, failing memop: don't indicate suppression Janis Schoetterl-Glausch
2022-04-25 10:01 ` Janis Schoetterl-Glausch [this message]
2022-04-25 13:46   ` [PATCH v2 1/2] KVM: s390: Don't indicate suppression on dirtying, failing memop Claudio Imbrenda
2022-04-25 16:01   ` Christian Borntraeger
2022-04-26  7:18   ` Janosch Frank
2022-04-26 13:25     ` Janis Schoetterl-Glausch
2022-04-26 13:39       ` Janosch Frank
2022-04-25 10:01 ` [PATCH v2 2/2] KVM: s390: selftest: Test suppression indication on key prot exception Janis Schoetterl-Glausch
2022-04-25 13:47   ` Claudio Imbrenda
2022-04-28 16:48   ` Janis Schoetterl-Glausch
2022-04-25 16:30 ` [PATCH v2 0/2] Dirtying, failing memop: don't indicate suppression Christian Borntraeger
2022-04-25 17:29   ` Janis Schoetterl-Glausch
2022-04-26  6:19     ` Christian Borntraeger
2022-04-26  7:25       ` Janosch Frank
2022-04-26 11:56         ` Janis Schoetterl-Glausch
2022-04-26 12:34           ` Janosch Frank
2022-05-02  7:58         ` Christian Borntraeger

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=20220425100147.1755340-2-scgl@linux.ibm.com \
    --to=scgl@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.org \
    --cc=svens@linux.ibm.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.