From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>,
Janis Schoetterl-Glausch <scgl@linux.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 1/2] KVM: s390: Don't indicate suppression on dirtying, failing memop
Date: Thu, 12 May 2022 18:26:44 +0200 [thread overview]
Message-ID: <9ad7acb4-2729-15bb-7b25-eb95c4a12f09@linux.ibm.com> (raw)
In-Reply-To: <701033df-49c5-987e-b316-40835ad83d16@redhat.com>
Am 12.05.22 um 17:50 schrieb David Hildenbrand:
> On 12.05.22 15:51, Christian Borntraeger wrote:
>>
>>
>> Am 12.05.22 um 15:22 schrieb David Hildenbrand:
>>> On 12.05.22 15:10, Janis Schoetterl-Glausch wrote:
>>>> 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 may have modified guest memory, as a result, the likely
>>>> correct ending is termination. Therefore, do not indicate a
>>>> suppressing instruction ending in this case.
>>>
>>> I think that is possibly problematic handling.
>>>
>>> In TCG we stumbled in similar issues in the past for MVC when crossing
>>> page boundaries. Failing after modifying the first page already
>>> seriously broke some user space, because the guest would retry the
>>> instruction after fixing up the fault reason on the second page: if
>>> source and destination operands overlap, you'll be in trouble because
>>> the input parameters already changed.
>>>
>>> For this reason, in TCG we make sure that all accesses are valid before
>>> starting modifications.
>>>
>>> See target/s390x/tcg/mem_helper.c:do_helper_mvc with access_prepare()
>>> and friends as an example.
>>>
>>> Now, I don't know how to tackle that for KVM, I just wanted to raise
>>> awareness that injecting an interrupt after modifying page content is
>>> possible dodgy and dangerous.
>>
>> this is really special and only for key protection crossing pages.
>> Its been done since the 70ies in that way on z/VM. The architecture
>> is and was always written in a way to allow termination for this
>> case for hypervisors.
>
> Just so I understand correctly: all instructions that a hypervisor with
> hardware virtualization is supposed to emulate are "written in a way to
> allow termination", correct? That makes things a lot easier.
Only for key protection. Key protection can always be terminating no matter
what the instruction says. This is historical baggage - key protection was
resulting in abends - killing the process. So it does not matter if we
provide the extra info as in enhanced suppression on protection as nobody
is making use of that (apart from debuggers maybe).
next prev parent reply other threads:[~2022-05-12 16:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-12 13:10 [PATCH v3 0/2] Dirtying, failing memop: don't indicate suppression Janis Schoetterl-Glausch
2022-05-12 13:10 ` [PATCH v3 1/2] KVM: s390: Don't indicate suppression on dirtying, failing memop Janis Schoetterl-Glausch
2022-05-12 13:22 ` David Hildenbrand
2022-05-12 13:51 ` Christian Borntraeger
2022-05-12 15:50 ` David Hildenbrand
2022-05-12 16:26 ` Christian Borntraeger [this message]
2022-05-12 16:40 ` David Hildenbrand
2022-05-17 12:25 ` Christian Borntraeger
2022-05-17 14:45 ` Claudio Imbrenda
2022-05-12 13:10 ` [PATCH v3 2/2] KVM: s390: selftest: Test suppression indication on key prot exception Janis Schoetterl-Glausch
2022-05-17 12:26 ` Christian Borntraeger
2022-05-17 12:28 ` [PATCH v3 0/2] Dirtying, failing memop: don't indicate suppression 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=9ad7acb4-2729-15bb-7b25-eb95c4a12f09@linux.ibm.com \
--to=borntraeger@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=corbet@lwn.net \
--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-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=scgl@linux.ibm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox