public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: kvm@vger.kernel.org
Cc: ajones@ventanamicro.com, yan.y.zhao@intel.com,
	kevin.tian@intel.com, jgg@nvidia.com, peterx@redhat.com
Subject: Re: [PATCH] vfio/pci: Insert full vma on mmap'd MMIO fault
Date: Tue, 11 Jun 2024 09:23:33 -0600	[thread overview]
Message-ID: <20240611092333.6bb17d60.alex.williamson@redhat.com> (raw)
In-Reply-To: <20240607035213.2054226-1-alex.williamson@redhat.com>


Any support for this or should we just go with the v2 series[1] by
itself for v6.10?  Thanks,

Alex

[1]https://lore.kernel.org/all/20240530045236.1005864-1-alex.williamson@redhat.com/

On Thu,  6 Jun 2024 21:52:07 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:

> In order to improve performance of typical scenarios we can try to insert
> the entire vma on fault.  This accelerates typical cases, such as when
> the MMIO region is DMA mapped by QEMU.  The vfio_iommu_type1 driver will
> fault in the entire DMA mapped range through fixup_user_fault().
> 
> In synthetic testing, this improves the time required to walk a PCI BAR
> mapping from userspace by roughly 1/3rd.
> 
> This is likely an interim solution until vmf_insert_pfn_{pmd,pud}() gain
> support for pfnmaps.
> 
> Suggested-by: Yan Zhao <yan.y.zhao@intel.com>
> Link: https://lore.kernel.org/all/Zl6XdUkt%2FzMMGOLF@yzhao56-desk.sh.intel.com/
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
> 
> I'm sending this as a follow-on patch to the v2 series[1] because this
> is largely a performance optimization, and one that we may want to
> revert when we can introduce huge_fault support.  In the meantime, I
> can't argue with the 1/3rd performance improvement this provides to
> reduce the overall impact of the series below.  Without objection I'd
> therefore target this for v6.10 as well.  Thanks,
> 
> Alex
> 
> [1]https://lore.kernel.org/all/20240530045236.1005864-1-alex.williamson@redhat.com/
> 
>  drivers/vfio/pci/vfio_pci_core.c | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index db31c27bf78b..987c7921affa 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -1662,6 +1662,7 @@ static vm_fault_t vfio_pci_mmap_fault(struct vm_fault *vmf)
>  	struct vm_area_struct *vma = vmf->vma;
>  	struct vfio_pci_core_device *vdev = vma->vm_private_data;
>  	unsigned long pfn, pgoff = vmf->pgoff - vma->vm_pgoff;
> +	unsigned long addr = vma->vm_start;
>  	vm_fault_t ret = VM_FAULT_SIGBUS;
>  
>  	pfn = vma_to_pfn(vma);
> @@ -1669,11 +1670,25 @@ static vm_fault_t vfio_pci_mmap_fault(struct vm_fault *vmf)
>  	down_read(&vdev->memory_lock);
>  
>  	if (vdev->pm_runtime_engaged || !__vfio_pci_memory_enabled(vdev))
> -		goto out_disabled;
> +		goto out_unlock;
>  
>  	ret = vmf_insert_pfn(vma, vmf->address, pfn + pgoff);
> +	if (ret & VM_FAULT_ERROR)
> +		goto out_unlock;
>  
> -out_disabled:
> +	/*
> +	 * Pre-fault the remainder of the vma, abort further insertions and
> +	 * supress error if fault is encountered during pre-fault.
> +	 */
> +	for (; addr < vma->vm_end; addr += PAGE_SIZE, pfn++) {
> +		if (addr == vmf->address)
> +			continue;
> +
> +		if (vmf_insert_pfn(vma, addr, pfn) & VM_FAULT_ERROR)
> +			break;
> +	}
> +
> +out_unlock:
>  	up_read(&vdev->memory_lock);
>  
>  	return ret;


  reply	other threads:[~2024-06-11 15:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  3:52 [PATCH] vfio/pci: Insert full vma on mmap'd MMIO fault Alex Williamson
2024-06-11 15:23 ` Alex Williamson [this message]
2024-06-12 10:08   ` Yan Zhao
2024-06-12 12:17   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240611092333.6bb17d60.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=ajones@ventanamicro.com \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=peterx@redhat.com \
    --cc=yan.y.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox