From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: Douglas Freimuth <freimuth@linux.ibm.com>,
imbrenda@linux.ibm.com, frankja@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 v1 1/3] Add map/unmap ioctl and clean mappings post-guest
Date: Mon, 9 Mar 2026 19:15:47 +0100 [thread overview]
Message-ID: <af6dd289-eb40-4c3d-acd2-c0b698cc4f73@linux.ibm.com> (raw)
In-Reply-To: <0ecd8210-e97a-4a5a-a9f2-513b7a323984@linux.ibm.com>
Am 09.03.26 um 18:12 schrieb Douglas Freimuth:
>
>
> On 3/9/26 5:27 AM, Christian Borntraeger wrote:
>> Am 08.03.26 um 04:04 schrieb Douglas Freimuth:
>>> Fencing of Fast Inject in Secure Execution environments is enabled in
>>> this patch by not mapping adapter indicator pages. In Secure Execution
>> [...]
>>
>>> @@ -2477,14 +2572,28 @@ static int modify_io_adapter(struct kvm_device *dev,
>>> 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;
>>> + mutex_lock(&dev->kvm->lock);
>>> + if (kvm_s390_pv_is_protected(dev->kvm)) {
>>> + mutex_unlock(&dev->kvm->lock);
>>> + break;
>>> + }
>>
>>
>> I guess this works for a well behaving userspaces, but a bad QEMU could in theory
>> not do the unmap on switch to secure.
>> Shall we maybe do -EINVAL on KVM_PV_ENABLE if there are still mapping left, or
>> to make it easier for userspace remove the old ADAPTER maps?
>>
>
> Christian, thank you for your input. For this scenario, I will look into adding/testing removing the old adapter maps. I will start in kvm_s390_handle_pv() for CASE KVM_PV_ENABLE and I will essentially use most of the functionality in kvm_s390_destroy_adapters() where the maps are deleted if they exist.
Right, maybe just add a unmap_all_adapters function and call that.
>
> Discussion: During development and test I realized it appears a guest can only change state between non-SE and SE during a reboot. Thus the unmap and map is called which hits the fencing in the current patch. Additionally, a more draconian fencing could possibly be done if needed, by checking for the existence of SE firmware in the CMDLINE and prevent any mapping from occurring on those systems that support SE.
Yes, diagnose 308 code 10 switches in a reboot like style to secure and diagnose 308 code 3 or 4 switch back to non secure.
next prev parent reply other threads:[~2026-03-09 18:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 3:04 [PATCH v1 0/3] KVM: s390: Introducing kvm_arch_set_irq_inatomic Fast Inject Douglas Freimuth
2026-03-08 3:04 ` [PATCH v1 1/3] Add map/unmap ioctl and clean mappings post-guest Douglas Freimuth
2026-03-08 13:15 ` kernel test robot
2026-03-09 9:27 ` Christian Borntraeger
2026-03-09 17:12 ` Douglas Freimuth
2026-03-09 18:15 ` Christian Borntraeger [this message]
2026-03-09 14:41 ` Sean Christopherson
2026-03-11 20:24 ` Matthew Rosato
2026-03-08 3:04 ` [PATCH v1 2/3] Enable adapter_indicators_set to use mapped pages Douglas Freimuth
2026-03-11 20:24 ` Matthew Rosato
2026-03-08 3:04 ` [PATCH v1 3/3] Introducing kvm_arch_set_irq_inatomic fast inject Douglas Freimuth
2026-03-11 20:24 ` Matthew Rosato
2026-03-13 14:01 ` Douglas Freimuth
2026-03-16 15:41 ` Matthew Rosato
2026-03-17 13:06 ` Douglas Freimuth
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=af6dd289-eb40-4c3d-acd2-c0b698cc4f73@linux.ibm.com \
--to=borntraeger@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=freimuth@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