[v1] KVM: s390: Fall back to short-term pinning in MAP ioctl

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

Posted by Jaehoon Kim 4 days, 3 hours ago

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,
immediately unpin the page and return success. 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.

Fixes: adcd5b3e758b ("KVM: s390: Add map/unmap ioctl and clean mappings post-guest")
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
---
 arch/s390/kvm/interrupt.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 9e3e6b0d72ad..4b68e0cb51f6 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -2520,8 +2520,19 @@ static int kvm_s390_adapter_map(struct kvm *kvm, unsigned int id, __u64 addr)
 	map->addr = host_addr;
 	map->page = pin_map_page(kvm, host_addr, FOLL_LONGTERM);
 	if (!map->page) {
-		ret = -EINVAL;
-		goto out;
+		/*
+		 * Long-term pinning may fail for memory types such as file-backed
+		 * memory. Check whether short-term pinning is possible so that the
+		 * non-atomic irqfd path can handle interrupt injection.
+		 */
+		map->page = pin_map_page(kvm, host_addr, 0);
+		if (!map->page) {
+			ret = -EINVAL;
+			goto out;
+		}
+		unpin_user_page(map->page);
+		kfree(map);
+		return 0;
 	}
 	spin_lock_irqsave(&adapter->maps_lock, flags);
 	if (adapter->nr_maps < MAX_S390_ADAPTER_MAPS) {
-- 
2.43.0

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

Posted by Matthew Rosato 2 days, 9 hours ago

On 7/20/26 6:22 PM, Jaehoon Kim wrote:
> 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,
> immediately unpin the page and return success. 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.
> 
> Fixes: adcd5b3e758b ("KVM: s390: Add map/unmap ioctl and clean mappings post-guest")
> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
> ---
>  arch/s390/kvm/interrupt.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 9e3e6b0d72ad..4b68e0cb51f6 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -2520,8 +2520,19 @@ static int kvm_s390_adapter_map(struct kvm *kvm, unsigned int id, __u64 addr)
>  	map->addr = host_addr;
>  	map->page = pin_map_page(kvm, host_addr, FOLL_LONGTERM);
>  	if (!map->page) {
> -		ret = -EINVAL;
> -		goto out;
> +		/*
> +		 * Long-term pinning may fail for memory types such as file-backed
> +		 * memory. Check whether short-term pinning is possible so that the
> +		 * non-atomic irqfd path can handle interrupt injection.
> +		 */
> +		map->page = pin_map_page(kvm, host_addr, 0);
> +		if (!map->page) {
> +			ret = -EINVAL;
> +			goto out;
> +		}
> +		unpin_user_page(map->page);
> +		kfree(map);
> +		return 0;

This makes sense, but what happens later on the kvm_s390_adapter_unmap?

Won't we return -ENOENT because nothing was in the list?

Is it worth detecting/recognizing this case?  I could think of 2 ways...

1) re-doing the above test during unmap

2) stashing an entry in adapter->maps but with a new flag that indicates
it was approved for short-term pinning only (e.g. return NULL
immediately if a match is found during get_map_info() with this flag
set), and during kvm_s390_adapter_unmap() and
kvm_s390_unmap_all_adapters() just remove it from the list without doing
any unpin/page dirtying.

#2 might be a little more code but sounds cleaner?

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

Posted by Christian Borntraeger 2 days, 8 hours ago


Am 22.07.26 um 17:51 schrieb Matthew Rosato:
> On 7/20/26 6:22 PM, Jaehoon Kim wrote:
>> 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,
>> immediately unpin the page and return success. 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.
>>
>> Fixes: adcd5b3e758b ("KVM: s390: Add map/unmap ioctl and clean mappings post-guest")
>> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
>> ---
>>   arch/s390/kvm/interrupt.c | 15 +++++++++++++--
>>   1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
>> index 9e3e6b0d72ad..4b68e0cb51f6 100644
>> --- a/arch/s390/kvm/interrupt.c
>> +++ b/arch/s390/kvm/interrupt.c
>> @@ -2520,8 +2520,19 @@ static int kvm_s390_adapter_map(struct kvm *kvm, unsigned int id, __u64 addr)
>>   	map->addr = host_addr;
>>   	map->page = pin_map_page(kvm, host_addr, FOLL_LONGTERM);
>>   	if (!map->page) {
>> -		ret = -EINVAL;
>> -		goto out;
>> +		/*
>> +		 * Long-term pinning may fail for memory types such as file-backed
>> +		 * memory. Check whether short-term pinning is possible so that the
>> +		 * non-atomic irqfd path can handle interrupt injection.
>> +		 */
>> +		map->page = pin_map_page(kvm, host_addr, 0);
>> +		if (!map->page) {
>> +			ret = -EINVAL;
>> +			goto out;
>> +		}
>> +		unpin_user_page(map->page);
>> +		kfree(map);
>> +		return 0;
> 
> This makes sense, but what happens later on the kvm_s390_adapter_unmap?
> 
> Won't we return -ENOENT because nothing was in the list?
> 
> Is it worth detecting/recognizing this case?  I could think of 2 ways...
> 
> 1) re-doing the above test during unmap
> 
> 2) stashing an entry in adapter->maps but with a new flag that indicates
> it was approved for short-term pinning only (e.g. return NULL
> immediately if a match is found during get_map_info() with this flag
> set), and during kvm_s390_adapter_unmap() and
> kvm_s390_unmap_all_adapters() just remove it from the list without doing
> any unpin/page dirtying.
> 
> #2 might be a little more code but sounds cleaner?
> 

When we are at it, can we also fix  Documentation/virt/kvm/devices/s390_flic.rst ?

To me it looks like qemu does not check the error for unmapping, but yes, maybe 2 is
the right thing to do.

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

Posted by JAEHOON KIM 2 days, 7 hours ago

On 7/22/2026 12:07 PM, Christian Borntraeger wrote:
>
>
> Am 22.07.26 um 17:51 schrieb Matthew Rosato:
>> On 7/20/26 6:22 PM, Jaehoon Kim wrote:
>>> 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,
>>> immediately unpin the page and return success. 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.
>>>
>>> Fixes: adcd5b3e758b ("KVM: s390: Add map/unmap ioctl and clean 
>>> mappings post-guest")
>>> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
>>> ---
>>>   arch/s390/kvm/interrupt.c | 15 +++++++++++++--
>>>   1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
>>> index 9e3e6b0d72ad..4b68e0cb51f6 100644
>>> --- a/arch/s390/kvm/interrupt.c
>>> +++ b/arch/s390/kvm/interrupt.c
>>> @@ -2520,8 +2520,19 @@ static int kvm_s390_adapter_map(struct kvm 
>>> *kvm, unsigned int id, __u64 addr)
>>>       map->addr = host_addr;
>>>       map->page = pin_map_page(kvm, host_addr, FOLL_LONGTERM);
>>>       if (!map->page) {
>>> -        ret = -EINVAL;
>>> -        goto out;
>>> +        /*
>>> +         * Long-term pinning may fail for memory types such as 
>>> file-backed
>>> +         * memory. Check whether short-term pinning is possible so 
>>> that the
>>> +         * non-atomic irqfd path can handle interrupt injection.
>>> +         */
>>> +        map->page = pin_map_page(kvm, host_addr, 0);
>>> +        if (!map->page) {
>>> +            ret = -EINVAL;
>>> +            goto out;
>>> +        }
>>> +        unpin_user_page(map->page);
>>> +        kfree(map);
>>> +        return 0;
>>
>> This makes sense, but what happens later on the kvm_s390_adapter_unmap?
>>
>> Won't we return -ENOENT because nothing was in the list?
>>
>> Is it worth detecting/recognizing this case?  I could think of 2 ways...
>>
>> 1) re-doing the above test during unmap
>>
>> 2) stashing an entry in adapter->maps but with a new flag that indicates
>> it was approved for short-term pinning only (e.g. return NULL
>> immediately if a match is found during get_map_info() with this flag
>> set), and during kvm_s390_adapter_unmap() and
>> kvm_s390_unmap_all_adapters() just remove it from the list without doing
>> any unpin/page dirtying.
>>
>> #2 might be a little more code but sounds cleaner?
>>
>
> When we are at it, can we also fix 
> Documentation/virt/kvm/devices/s390_flic.rst ?
>
> To me it looks like qemu does not check the error for unmapping, but 
> yes, maybe 2 is
> the right thing to do.

I agree that option #2 is the cleaner approach as well. I'll also update the
documentation.

Thanks,
Jaehoon.

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

Posted by Douglas Freimuth 4 days, 2 hours ago


On 7/20/26 6:22 PM, Jaehoon Kim wrote:
> 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,
> immediately unpin the page and return success. 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.
> 
> Fixes: adcd5b3e758b ("KVM: s390: Add map/unmap ioctl and clean mappings post-guest")
> Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
> ---
>   arch/s390/kvm/interrupt.c | 15 +++++++++++++--
>   1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 9e3e6b0d72ad..4b68e0cb51f6 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -2520,8 +2520,19 @@ static int kvm_s390_adapter_map(struct kvm *kvm, unsigned int id, __u64 addr)
>   	map->addr = host_addr;
>   	map->page = pin_map_page(kvm, host_addr, FOLL_LONGTERM);
>   	if (!map->page) {
> -		ret = -EINVAL;
> -		goto out;
> +		/*
> +		 * Long-term pinning may fail for memory types such as file-backed
> +		 * memory. Check whether short-term pinning is possible so that the
> +		 * non-atomic irqfd path can handle interrupt injection.
> +		 */
> +		map->page = pin_map_page(kvm, host_addr, 0);
> +		if (!map->page) {
> +			ret = -EINVAL;
> +			goto out;
> +		}
> +		unpin_user_page(map->page);
> +		kfree(map);
> +		return 0;
>   	}
>   	spin_lock_irqsave(&adapter->maps_lock, flags);
>   	if (adapter->nr_maps < MAX_S390_ADAPTER_MAPS) {

Reviewed-by: Douglas Freimuth <freimuth@linux.ibm.com>