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

[Matthew Rosato]

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@xxxxxxxxxxxxx>
>> Reviewed-by: Douglas Freimuth <freimuth@xxxxxxxxxxxxx>
>> Reviewed-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>
> 
> 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?