[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8095d0de-dd99-0388-b1d4-e59b01dc4be0@linux.ibm.com>
Date: Mon, 25 Apr 2022 18:30:26 +0200
From: Christian Borntraeger <borntraeger@...ux.ibm.com>
To: Janis Schoetterl-Glausch <scgl@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc: 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: Re: [PATCH v2 0/2] Dirtying, failing memop: don't indicate
suppression
Am 25.04.22 um 12:01 schrieb Janis Schoetterl-Glausch:
> 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.
>
Thanks applied. I think it makes sense for 5.18 nevertheless.
> 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
Powered by blists - more mailing lists