From: Matt Evans <mattev@meta.com>
To: Alex Williamson <alex@shazbot.org>,
Kevin Tian <kevin.tian@intel.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Ankit Agrawal <ankita@nvidia.com>,
Alistair Popple <apopple@nvidia.com>,
Leon Romanovsky <leon@kernel.org>, Kees Cook <kees@kernel.org>,
Shameer Kolothum <skolothumtho@nvidia.com>,
Yishai Hadas <yishaih@nvidia.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
Eric Auger <eric.auger@redhat.com>, Peter Xu <peterx@redhat.com>,
Vivek Kasireddy <vivek.kasireddy@intel.com>,
Zhi Wang <zhiw@nvidia.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <virtualization@lists.linux.dev>
Subject: [PATCH 2/2] vfio/pci: Remove vfio_pci_core_setup_barmap()
Date: Tue, 21 Apr 2026 10:41:41 -0700 [thread overview]
Message-ID: <20260421174143.3883579-3-mattev@meta.com> (raw)
In-Reply-To: <20260421174143.3883579-1-mattev@meta.com>
Since "vfio/pci: Set up barmap in vfio_pci_core_enable()", the BAR
mapping and resource acquisition are done at setup time, and most uses
of vfio_pci_core_setup_barmap() are now unnecessary. Remove the
callers, and the function.
Some callers used it to also test if a mapping is present before a
direct access, and these places now do a simple test of
vdev->barmap[].
Signed-off-by: Matt Evans <mattev@meta.com>
---
drivers/vfio/pci/nvgrace-gpu/main.c | 11 +++++------
drivers/vfio/pci/vfio_pci_core.c | 8 --------
drivers/vfio/pci/vfio_pci_rdwr.c | 22 ++++------------------
drivers/vfio/pci/virtio/legacy_io.c | 5 ++---
4 files changed, 11 insertions(+), 35 deletions(-)
diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c
index fa056b69f899..3712f6b54d46 100644
--- a/drivers/vfio/pci/nvgrace-gpu/main.c
+++ b/drivers/vfio/pci/nvgrace-gpu/main.c
@@ -184,14 +184,13 @@ static int nvgrace_gpu_open_device(struct vfio_device *core_vdev)
/*
* GPU readiness is checked by reading the BAR0 registers.
- *
- * ioremap BAR0 to ensure that the BAR0 mapping is present before
- * register reads on first fault before establishing any GPU
- * memory mapping.
+ * BARs should have been mapped at device enable, but it's
+ * good to assert they're present before the access:
*/
- ret = vfio_pci_core_setup_barmap(vdev, 0);
- if (ret)
+ if (!vdev->barmap[0]) {
+ ret = -EINVAL;
goto error_exit;
+ }
if (nvdev->resmem.memlength) {
ret = nvgrace_gpu_vfio_pci_register_pfn_range(core_vdev, &nvdev->resmem);
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 4a314213f3ae..228d92ce61d1 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1805,14 +1805,6 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
if (req_start + req_len > phys_len)
return -EINVAL;
- /*
- * Even though we don't make use of the barmap for the mmap,
- * we need to request the region and the barmap tracks that.
- */
- ret = vfio_pci_core_setup_barmap(vdev, index);
- if (ret)
- return ret;
-
vma->vm_private_data = vdev;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index d1386a31a3a3..21e19ed48bf5 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -198,18 +198,6 @@ ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem,
}
EXPORT_SYMBOL_GPL(vfio_pci_core_do_io_rw);
-int vfio_pci_core_setup_barmap(struct vfio_pci_core_device *vdev, int bar)
-{
- /*
- * The barmap is now always set up in vfio_pci_core_enable().
- * Some legacy callers use this function to check if the BAR
- * is legitimate, so maintain that:
- */
-
- return vdev->barmap[bar] ? 0 : -EBUSY;
-}
-EXPORT_SYMBOL_GPL(vfio_pci_core_setup_barmap);
-
ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf,
size_t count, loff_t *ppos, bool iswrite)
{
@@ -261,9 +249,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf,
*/
max_width = VFIO_PCI_IO_WIDTH_4;
} else {
- int ret = vfio_pci_core_setup_barmap(vdev, bar);
- if (ret) {
- done = ret;
+ if (!vdev->barmap[bar]) {
+ done = -EINVAL;
goto out;
}
@@ -439,9 +426,8 @@ int vfio_pci_ioeventfd(struct vfio_pci_core_device *vdev, loff_t offset,
if (count == 8)
return -EINVAL;
- ret = vfio_pci_core_setup_barmap(vdev, bar);
- if (ret)
- return ret;
+ if (!vdev->barmap[bar])
+ return -EINVAL;
mutex_lock(&vdev->ioeventfds_lock);
diff --git a/drivers/vfio/pci/virtio/legacy_io.c b/drivers/vfio/pci/virtio/legacy_io.c
index 1ed349a55629..67f93b96c099 100644
--- a/drivers/vfio/pci/virtio/legacy_io.c
+++ b/drivers/vfio/pci/virtio/legacy_io.c
@@ -305,9 +305,8 @@ static int virtiovf_set_notify_addr(struct virtiovf_pci_core_device *virtvdev)
* Setup the BAR where the 'notify' exists to be used by vfio as well
* This will let us mmap it only once and use it when needed.
*/
- ret = vfio_pci_core_setup_barmap(core_device,
- virtvdev->notify_bar);
- if (ret)
+ if (virtvdev->notify_bar >= PCI_STD_NUM_BARS ||
+ !core_device->barmap[virtvdev->notify_bar])
return ret;
virtvdev->notify_addr = core_device->barmap[virtvdev->notify_bar] +
--
2.47.3
prev parent reply other threads:[~2026-04-21 17:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 17:41 [PATCH 0/2] vfio/pci: Request resources and map BARs at enable time Matt Evans
2026-04-21 17:41 ` [PATCH 1/2] vfio/pci: Set up barmap in vfio_pci_core_enable() Matt Evans
2026-04-21 19:31 ` Alex Williamson
2026-04-23 14:18 ` Matt Evans
2026-04-21 17:41 ` Matt Evans [this message]
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=20260421174143.3883579-3-mattev@meta.com \
--to=mattev@meta.com \
--cc=aik@ozlabs.ru \
--cc=alex@shazbot.org \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=eric.auger@redhat.com \
--cc=jgg@ziepe.ca \
--cc=kees@kernel.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterx@redhat.com \
--cc=skolothumtho@nvidia.com \
--cc=virtualization@lists.linux.dev \
--cc=vivek.kasireddy@intel.com \
--cc=yishaih@nvidia.com \
--cc=zhiw@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.