Re: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[JAEHOON KIM <jhkim@linux.ibm.com>]

On 7/28/2026 11:21 AM, Matthew Rosato wrote:
> On 7/27/26 3:29 AM, Christian Borntraeger wrote:
>> Am 24.07.26 um 15:39 schrieb Jaehoon Kim:
>>> FOLL_LONGTERM pinning fails for some memory types, such as file-backed
>>> guest memory. As a result, kvm_s390_adapter_map() returns -EINVAL and
>>> irqfd adapter registration fails even though interrupt delivery could
>>> still work via the existing non-atomic path.
>>>
>>> When FOLL_LONGTERM pinning fails, verify that the page is accessible
>>> using a short-term pin instead. If the short-term pin succeeds, unpin
>>> the page and add a map entry with pinned=false to preserve MAP/UNMAP
>>> symmetry. The non-atomic irqfd path already performs short-term pinning
>>> for interrupt delivery, so this restores the previous behavior for
>>> memory that cannot be pinned long-term.
>>>
>>> get_map_info() is updated to return NULL for unpinned entries so that
>>> the atomic irqfd fast path falls back to the non-atomic path.
>>> kvm_s390_adapter_unmap() and kvm_s390_unmap_all_adapters() skip dirty
>>> marking and unpin for unpinned entries.
>>>
>>> Update Documentation/virt/kvm/devices/s390_flic.rst to reflect the
>>> new MAP/UNMAP behavior.
>>>
>>> Fixes: c9a568838086 ("KVM: s390: Add map/unmap ioctl and clean
>>> mappings post-guest")
>>> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
>>> Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com>
>>> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
>> queued for kvm/master.
>>
>> Doug, Jaehoon, Matt,
>>
>> can you have a look at the sashiko feedback for the pre-existing issue
>> and work on a
>> followup fix?
>>
> I believe this report is not nearly as extreme as it sounds.
>
> It claims:
> "If a malicious guest or untrusted userspace configures an IRQ routing
> entry with an unmapped host virtual address for summary_addr, the
> short-term pin will fail:"
>
> However: the summary_page was previously validated when the route was
> setup in kvm_set_routing_entry():
>
> uaddr_s = gpa_to_hva(kvm, ue->u.adapter.summary_addr);
> ...
> if (kvm_is_error_hva(uaddr_s) || kvm_is_error_hva(uaddr_i))
> 	return -EFAULT;
> e->adapter.summary_addr = uaddr_s;
>
> So we already know that the address was pre-validated before we try to
> use it in adapter_indicators_set().  BTW this is similar to what Janosch
> did for
> dcf96f7ad556 KVM: s390: Limit adapter indicator access to mapped page
>
> I think we could only have some problem if we later remove a memslot
> that happened to have the summary page on it such that the up-front
> validation is no longer accurate?  Can this even happen?
>
> So: Not nearly as easy or user-controlled as 'guest provides bogus
> address, crashing panic_on_warn=1 host'
>
> All that said:
> The only reason this case is 'weird' is because we may have already
> indicated AIBV successfully (made changes to the guest) but cannot
> complete delivery because AISB is unreachable.
> Maybe the simple answer is to downgrade this to something like
> pr_warn_once("Cannot indicate summary on previously-validated routing
> entry") so we don't lose the breadcrumbs for this highly-unlikely
> scenario but also don't add the potential panic in the first place?  If
> we ever reach this situation, the guest in question is going to get bits
> set in AIBV but will likely never see them because it will poll first on
> AISB which we cannot set anymore.
>
>
> That would track with
> https://docs.kernel.org/process/coding-style.html#do-not-warn-lightly
> even if I don't think it's easy to trigger.
>
> Doug / Jaehoon / s390 KVM maintainers -- thoughts?

Thanks for clarifying. I agree that this is different from the original
Sashiko concern, since the address is already validated. pr_warn_once()
sounds like a good balance to keep the breadcrumb while avoiding a
potential panic.