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

[Douglas Freimuth <freimuth@linux.ibm.com>]

On 7/28/26 12:47 PM, JAEHOON KIM wrote:
> 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.
> 

The answer depends on the environment the system is running in. If it is 
running in an environment with tight tolerances for good reason then we 
might want to panic since the error state should be rare and we have 
note warned lightly. Tight tolerances can be set by enabling panic on 
WARN_ON_ONCE.

The admin knows how tightly they want to control the system so if they 
dont configure panic on WARN_ON_ONCE then this is just logged as desired 
without panic.

If we are concerned or have observed that the usage of panic for 
WARN_ON_ONCE is not done very discreetly then pr_warn_once("Cannot 
indicate summary on previously-validated routing
entry") is the answer.