[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220425100147.1755340-1-scgl@linux.ibm.com>
Date: Mon, 25 Apr 2022 12:01:45 +0200
From: Janis Schoetterl-Glausch <scgl@...ux.ibm.com>
To: Christian Borntraeger <borntraeger@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc: Janis Schoetterl-Glausch <scgl@...ux.ibm.com>,
David Hildenbrand <david@...hat.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org
Subject: [PATCH v2 0/2] Dirtying, failing memop: don't indicate suppression
If a memop fails due to key checked protection, after already having
written to the guest, don't indicate suppression to the guest, as that
would imply that memory wasn't modified.
This could be considered a fix to the code introducing storage key
support, however this is a bug in KVM only if we emulate an
instructions writing to an operand spanning multiple pages, which I
don't believe we do.
v1 -> v2
* Reword commit message of patch 1
Janis Schoetterl-Glausch (2):
KVM: s390: Don't indicate suppression on dirtying, failing memop
KVM: s390: selftest: Test suppression indication on key prot exception
arch/s390/kvm/gaccess.c | 47 ++++++++++++++---------
tools/testing/selftests/kvm/s390x/memop.c | 43 ++++++++++++++++++++-
2 files changed, 70 insertions(+), 20 deletions(-)
base-commit: af2d861d4cd2a4da5137f795ee3509e6f944a25b
--
2.32.0
Powered by blists - more mailing lists