From: Douglas Freimuth <freimuth@linux.ibm.com>
To: Janosch Frank <frankja@linux.ibm.com>,
borntraeger@linux.ibm.com, imbrenda@linux.ibm.com,
david@kernel.org, hca@linux.ibm.com, gor@linux.ibm.com,
agordeev@linux.ibm.com, svens@linux.ibm.com, kvm@vger.kernel.org,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: mjrosato@linux.ibm.com
Subject: Re: [PATCH v2 1/3] KVM: s390: Add map/unmap ioctl and clean mappings post-guest
Date: Fri, 27 Mar 2026 11:31:34 -0400 [thread overview]
Message-ID: <5f03d78f-07d7-4e53-816b-4ff5306fc6c4@linux.ibm.com> (raw)
In-Reply-To: <259c135b-2c1b-4f43-a177-925d7df8b909@linux.ibm.com>
On 3/26/26 11:56 AM, Janosch Frank wrote:
> On 3/26/26 02:42, Douglas Freimuth wrote:
>> S390 needs map/unmap ioctls, which map the adapter set
>> indicator pages, so the pages can be accessed when interrupts are
>> disabled. The mappings are cleaned up when the guest is removed.
>>
>> Map/Unmap ioctls are fenced in order to avoid the longterm pinning
>> in Secure Execution environments. In Secure Execution
>> environments the path of execution available before this patch is
>> followed.
>>
>> Statistical counters to count map/unmap functions for adapter indicator
>> pages are added. The counters can be used to analyze
>> map/unmap functions in non-Secure Execution environments and similarly
>> can be used to analyze Secure Execution environments where the counters
>> will not be incremented as the adapter indicator pages are not mapped.
>>
>> Signed-off-by: Douglas Freimuth <freimuth@linux.ibm.com>
>> ---
>
> Looks good, two nits below.
>
> [...]
>> if (ret > 0)
>> ret = 0;
>> break;
>> - /*
>> - * The following operations are no longer needed and therefore
>> no-ops.
>> - * The gpa to hva translation is done when an IRQ route is set
>> up. The
>> - * set_irq code uses get_user_pages_remote() to do the actual write.
>> - */
>> case KVM_S390_IO_ADAPTER_MAP:
>> case KVM_S390_IO_ADAPTER_UNMAP:
>> - ret = 0;
>> + /* If in Secure Execution mode do not long term pin. */
>> + mutex_lock(&dev->kvm->lock);
>> + if (kvm_s390_pv_is_protected(dev->kvm)) {
>> + mutex_unlock(&dev->kvm->lock);
>> + return 0;
>> + }
>> + mutex_unlock(&dev->kvm->lock);
>> + idx = srcu_read_lock(&dev->kvm->srcu);
>> + host_addr = gpa_to_hva(dev->kvm, req.addr);
>> + if (kvm_is_error_hva(host_addr)) {
>> + srcu_read_unlock(&dev->kvm->srcu, idx);
>> + return -EFAULT;
>> + }
>
> Alignment issue
>
> [...]
>
I will correct that. (Surprised checkpatch strict didn't catch it.)
>> static int kvm_s390_handle_pv(struct kvm *kvm, struct kvm_pv_cmd *cmd)
>> {
>> const bool need_lock = (cmd->cmd != KVM_PV_ASYNC_CLEANUP_PERFORM);
>> @@ -2503,6 +2522,7 @@ static int kvm_s390_handle_pv(struct kvm *kvm,
>> struct kvm_pv_cmd *cmd)
>> switch (cmd->cmd) {
>> case KVM_PV_ENABLE: {
>> + kvm_s390_unmap_all_adapters_pv(kvm);
>
> Shouldn't this be located after the check that's below?
>
While all of my tests do not observe it, not sure if there is a state
change where anything is left mapped while in pv. There should not be so
I can move it after the check as you mention.
>> r = -EINVAL;
>> if (kvm_s390_pv_is_protected(kvm))
>> break;
>
next prev parent reply other threads:[~2026-03-27 15:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 1:42 [PATCH v2 0/3] KVM: s390: Introducing kvm_arch_set_irq_inatomic Fast Inject Douglas Freimuth
2026-03-26 1:42 ` [PATCH v2 1/3] KVM: s390: Add map/unmap ioctl and clean mappings post-guest Douglas Freimuth
2026-03-26 11:46 ` Christian Borntraeger
2026-03-27 15:22 ` Douglas Freimuth
2026-03-26 15:56 ` Janosch Frank
2026-03-27 15:31 ` Douglas Freimuth [this message]
2026-03-27 15:24 ` Matthew Rosato
2026-03-26 1:42 ` [PATCH v2 2/3] KVM: s390: Enable adapter_indicators_set to use mapped pages Douglas Freimuth
2026-03-27 15:25 ` Matthew Rosato
2026-03-26 1:42 ` [PATCH v2 3/3] KVM: s390: Introducing kvm_arch_set_irq_inatomic fast inject Douglas Freimuth
2026-03-27 15:59 ` Matthew Rosato
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=5f03d78f-07d7-4e53-816b-4ff5306fc6c4@linux.ibm.com \
--to=freimuth@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@kernel.org \
--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=mjrosato@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
Powered by JetHome