From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Peter Xu <peterx@redhat.com>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"ajones@ventanamicro.com" <ajones@ventanamicro.com>
Subject: Re: [PATCH 2/2] vfio/pci: Use unmap_mapping_range()
Date: Fri, 24 May 2024 10:22:40 -0300 [thread overview]
Message-ID: <20240524132240.GV20229@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB52764E958E6481A112649B5D8CF52@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, May 24, 2024 at 08:40:26AM +0000, Tian, Kevin wrote:
> > From: Peter Xu <peterx@redhat.com>
> > Sent: Friday, May 24, 2024 8:49 AM
> >
> > Hi, Yan,
> >
> > On Fri, May 24, 2024 at 08:39:37AM +0800, Yan Zhao wrote:
> > > On Thu, May 23, 2024 at 01:56:27PM -0600, Alex Williamson wrote:
> > > > With the vfio device fd tied to the address space of the pseudo fs
> > > > inode, we can use the mm to track all vmas that might be mmap'ing
> > > > device BARs, which removes our vma_list and all the complicated lock
> > > > ordering necessary to manually zap each related vma.
> > > >
> > > > Note that we can no longer store the pfn in vm_pgoff if we want to use
> > > > unmap_mapping_range() to zap a selective portion of the device fd
> > > > corresponding to BAR mappings.
> > > >
> > > > This also converts our mmap fault handler to use vmf_insert_pfn()
> > > Looks vmf_insert_pfn() does not call memtype_reserve() to reserve
> > memory type
> > > for the PFN on x86 as what's done in io_remap_pfn_range().
> > >
> > > Instead, it just calls lookup_memtype() and determine the final prot based
> > on
> > > the result from this lookup, which might not prevent others from reserving
> > the
> > > PFN to other memory types.
> >
> > I didn't worry too much on others reserving the same pfn range, as that
> > should be the mmio region for this device, and this device should be owned
> > by vfio driver.
>
> and the earliest point doing memtype_reserve() is here:
>
> vfio_pci_core_mmap()
> vdev->barmap[index] = pci_iomap(pdev, index, 0);
>
> >
> > However I share the same question, see:
> >
> > https://lore.kernel.org/r/20240523223745.395337-2-peterx@redhat.com
> >
> > So far I think it's not a major issue as VFIO always use UC- mem type, and
> > that's also the default. But I do also feel like there's something we can
> > do better, and I'll keep you copied too if I'll resend the series.
> >
>
> vfio-nvgrace uses WC. But it directly does remap_pfn_range() in its
> nvgrace_gpu_mmap() so not suffering from the issue here.
People keep asking for WC on normal VFIO PCI as well, we shouldn't
rule out, or at least provide a big warning comment what needs to be
fixed to allow it.
Jason
next prev parent reply other threads:[~2024-05-24 13:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 19:56 [PATCH 0/2] vfio/pci: vfio device address space mapping Alex Williamson
2024-05-23 19:56 ` [PATCH 1/2] vfio: Create vfio_fs_type with inode per device Alex Williamson
2024-05-24 13:24 ` Jason Gunthorpe
2024-05-29 23:59 ` Tian, Kevin
2024-05-23 19:56 ` [PATCH 2/2] vfio/pci: Use unmap_mapping_range() Alex Williamson
2024-05-24 0:39 ` Yan Zhao
2024-05-24 0:49 ` Peter Xu
2024-05-24 1:47 ` Yan Zhao
2024-05-28 18:42 ` Alex Williamson
2024-05-29 2:29 ` Yan Zhao
2024-05-29 3:12 ` Alex Williamson
2024-05-29 6:34 ` Yan Zhao
2024-05-29 16:50 ` Alex Williamson
2024-05-30 7:46 ` Yan Zhao
2024-05-24 8:40 ` Tian, Kevin
2024-05-24 13:22 ` Jason Gunthorpe [this message]
2024-05-24 23:15 ` Peter Xu
2024-05-24 13:42 ` Jason Gunthorpe
2024-05-30 0:09 ` Tian, Kevin
2024-05-30 2:22 ` Alex Williamson
2024-05-30 2:47 ` Tian, Kevin
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=20240524132240.GV20229@nvidia.com \
--to=jgg@nvidia.com \
--cc=ajones@ventanamicro.com \
--cc=alex.williamson@redhat.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