Re: [PATCH] vfio/type1: conditional rescheduling while pinning

[Alex Williamson <alex.williamson@redhat.com>]

On Wed, 12 Mar 2025 15:52:55 -0700
Keith Busch <kbusch@meta.com> wrote:

> From: Keith Busch <kbusch@kernel.org>
> 
> A large DMA mapping request can loop through dma address pinning for
> many pages. The repeated vmf_insert_pfn can be costly, so let the task
> reschedule as need to prevent CPU stalls.
> 
>  rcu: INFO: rcu_sched self-detected stall on CPU
>  rcu: 	36-....: (20999 ticks this GP) idle=b01c/1/0x4000000000000000 softirq=35839/35839 fqs=3538
>  rcu: 	         hardirqs   softirqs   csw/system
>  rcu: 	 number:        0        107            0
>  rcu: 	cputime:       50          0        10446   ==> 10556(ms)
>  rcu: 	(t=21075 jiffies g=377761 q=204059 ncpus=384)
> ...
>   <TASK>
>   ? asm_sysvec_apic_timer_interrupt+0x16/0x20
>   ? walk_system_ram_range+0x63/0x120
>   ? walk_system_ram_range+0x46/0x120
>   ? pgprot_writethrough+0x20/0x20
>   lookup_memtype+0x67/0xf0
>   track_pfn_insert+0x20/0x40
>   vmf_insert_pfn_prot+0x88/0x140
>   vfio_pci_mmap_huge_fault+0xf9/0x1b0 [vfio_pci_core]
>   __do_fault+0x28/0x1b0
>   handle_mm_fault+0xef1/0x2560
>   fixup_user_fault+0xf5/0x270
>   vaddr_get_pfns+0x169/0x2f0 [vfio_iommu_type1]
>   vfio_pin_pages_remote+0x162/0x8e0 [vfio_iommu_type1]
>   vfio_iommu_type1_ioctl+0x1121/0x1810 [vfio_iommu_type1]
>   ? futex_wake+0x1c1/0x260
>   x64_sys_call+0x234/0x17a0
>   do_syscall_64+0x63/0x130
>   ? exc_page_fault+0x63/0x130
>   entry_SYSCALL_64_after_hwframe+0x4b/0x53
> 
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
>  drivers/vfio/vfio_iommu_type1.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 50ebc9593c9d7..9ad5fcc2de7c7 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -679,6 +679,7 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, unsigned long vaddr,
>  
>  		if (unlikely(disable_hugepages))
>  			break;
> +		cond_resched();
>  	}
>  
>  out:

Hey Keith, is this still necessary with:

https://lore.kernel.org/all/20250218222209.1382449-1-alex.williamson@redhat.com/

This is currently in linux-next from the vfio next branch and should
pretty much eliminate any stalls related to DMA mapping MMIO BARs.
Also the code here has been refactored in next, so this doesn't apply
anyway, and if there is a resched still needed, this location would
only affect DMA mapping of memory, not device BARs.  Thanks,

Alex