From: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>
Cc: David Hildenbrand <david@redhat.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
kvm@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 06/10] KVM: s390: Add vm IOCTL for key checked guest absolute memory access
Date: Thu, 20 Jan 2022 13:23:06 +0100 [thread overview]
Message-ID: <8647fcaf-6d8a-4678-0695-4b1cc797b3b1@linux.ibm.com> (raw)
In-Reply-To: <069c72b6-457f-65c7-652e-e6eca7235fca@redhat.com>
On 1/20/22 11:38, Thomas Huth wrote:
> On 18/01/2022 10.52, Janis Schoetterl-Glausch wrote:
>> Channel I/O honors storage keys and is performed on absolute memory.
>> For I/O emulation user space therefore needs to be able to do key
>> checked accesses.
>> The vm IOCTL supports read/write accesses, as well as checking
>> if an access would succeed.
> ...
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index e3f450b2f346..dd04170287fd 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -572,6 +572,8 @@ struct kvm_s390_mem_op {
>> #define KVM_S390_MEMOP_LOGICAL_WRITE 1
>> #define KVM_S390_MEMOP_SIDA_READ 2
>> #define KVM_S390_MEMOP_SIDA_WRITE 3
>> +#define KVM_S390_MEMOP_ABSOLUTE_READ 4
>> +#define KVM_S390_MEMOP_ABSOLUTE_WRITE 5
>
> Not quite sure about this - maybe it is, but at least I'd like to see this discussed: Do we really want to re-use the same ioctl layout for both, the VM and the VCPU file handles? Where the userspace developer has to know that the *_ABSOLUTE_* ops only work with VM handles, and the others only work with the VCPU handles? A CPU can also address absolute memory, so why not adding the *_ABSOLUTE_* ops there, too? And if we'd do that, wouldn't it be sufficient to have the VCPU ioctls only - or do you want to call these ioctls from spots in QEMU where you do not have a VCPU handle available? (I/O instructions are triggered from a CPU, so I'd assume that you should have a VCPU handle around?)
There are some differences between the vm and the vcpu memops.
No storage or fetch protection overrides apply to IO/vm memops, after all there is no control register to enable them.
Additionally, quiescing is not required for IO, tho in practice we use the same code path for the vcpu and the vm here.
Allowing absolute accesses with a vcpu is doable, but I'm not sure what the use case for it would be, I'm not aware of
a precedence in the architecture. Of course the vcpu memop already supports logical=real accesses.
>
> Thomas
>
>
next prev parent reply other threads:[~2022-01-20 12:23 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 9:52 [RFC PATCH v1 00/10] KVM: s390: Do storage key checking Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 01/10] s390/uaccess: Add storage key checked access to user memory Janis Schoetterl-Glausch
2022-01-18 13:18 ` Janosch Frank
2022-01-18 15:37 ` Sven Schnelle
2022-01-18 15:52 ` Janis Schoetterl-Glausch
2022-01-19 9:48 ` Heiko Carstens
2022-01-19 11:02 ` Janis Schoetterl-Glausch
2022-01-19 13:20 ` Heiko Carstens
2022-01-20 8:34 ` Janis Schoetterl-Glausch
2022-01-20 12:56 ` Heiko Carstens
2022-01-20 18:19 ` Heiko Carstens
2022-01-21 7:32 ` Christian Borntraeger
2022-01-21 11:04 ` Heiko Carstens
2022-01-21 13:46 ` Janis Schoetterl-Glausch
2022-01-21 14:26 ` Heiko Carstens
2022-01-24 10:38 ` [RFC PATCH] uaccess: Add mechanism for " Janis Schoetterl-Glausch
2022-01-24 17:41 ` Heiko Carstens
2022-01-25 12:35 ` Janis Schoetterl-Glausch
2022-01-25 13:23 ` Heiko Carstens
2022-01-18 9:52 ` [RFC PATCH v1 02/10] KVM: s390: Honor storage keys when accessing guest memory Janis Schoetterl-Glausch
2022-01-18 14:38 ` Janosch Frank
2022-01-20 10:27 ` Christian Borntraeger
2022-01-20 10:30 ` Janis Schoetterl-Glausch
2022-01-19 19:27 ` Christian Borntraeger
2022-01-20 8:11 ` Janis Schoetterl-Glausch
2022-01-20 8:50 ` Christian Borntraeger
2022-01-20 8:58 ` Janis Schoetterl-Glausch
2022-01-20 9:06 ` Christian Borntraeger
2022-01-18 9:52 ` [RFC PATCH v1 03/10] KVM: s390: handle_tprot: Honor storage keys Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 04/10] KVM: s390: selftests: Test TEST PROTECTION emulation Janis Schoetterl-Glausch
2022-01-20 15:40 ` Janosch Frank
2022-01-21 11:03 ` Janis Schoetterl-Glausch
2022-01-21 12:28 ` Claudio Imbrenda
2022-01-21 13:50 ` Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 05/10] KVM: s390: Add optional storage key checking to MEMOP IOCTL Janis Schoetterl-Glausch
2022-01-18 11:51 ` Christian Borntraeger
2022-01-18 9:52 ` [RFC PATCH v1 06/10] KVM: s390: Add vm IOCTL for key checked guest absolute memory access Janis Schoetterl-Glausch
2022-01-19 11:52 ` Thomas Huth
2022-01-19 12:46 ` Christian Borntraeger
2022-01-19 12:53 ` Thomas Huth
2022-01-19 13:17 ` Janis Schoetterl-Glausch
2022-01-20 10:38 ` Thomas Huth
2022-01-20 11:20 ` Christian Borntraeger
2022-01-20 12:23 ` Janis Schoetterl-Glausch [this message]
2022-01-25 12:00 ` Thomas Huth
2022-01-27 16:29 ` Janis Schoetterl-Glausch
2022-01-27 17:34 ` Claudio Imbrenda
2022-01-18 9:52 ` [RFC PATCH v1 07/10] KVM: s390: Rename existing vcpu memop functions Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 08/10] KVM: s390: selftests: Test memops with storage keys Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 09/10] KVM: s390: Add capability for storage key extension of MEM_OP IOCTL Janis Schoetterl-Glausch
2022-01-18 15:12 ` Christian Borntraeger
2022-01-18 9:52 ` [RFC PATCH v1 10/10] KVM: s390: selftests: Make use of capability in MEM_OP test Janis Schoetterl-Glausch
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=8647fcaf-6d8a-4678-0695-4b1cc797b3b1@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-s390@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®