From: Matt Evans <mattev@meta.com>
To: Alex Williamson <alex@shazbot.org>
Cc: 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>,
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: Re: [PATCH v4 1/3] vfio/pci: Set up BAR resources and maps in vfio_pci_core_enable()
Date: Fri, 8 May 2026 15:14:10 +0100 [thread overview]
Message-ID: <339b4e0c-7c41-4585-83a3-a2cd9e7003ee@meta.com> (raw)
In-Reply-To: <20260507162116.3b9cbd98@shazbot.org>
Hi Alex,
On 07/05/2026 23:21, Alex Williamson wrote:
>
> On Tue, 5 May 2026 10:38:29 -0700
> Matt Evans <mattev@meta.com> wrote:
>
>> Previously BAR resource requests and the corresponding pci_iomap()
>> were performed on-demand and without synchronisation, which was racy.
>> Rather than add synchronisation, it's simplest to address this by
>> doing both activities from vfio_pci_core_enable().
>>
>> The resource allocation and/or pci_iomap() can still fail; their
>> status is tracked and existing calls to vfio_pci_core_setup_barmap()
>> will fail in a similar way to before. This keeps the point of failure
>> as observed by userspace the same, i.e. failures to request/map unused
>> BARs are benign.
>>
>> Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
>> Signed-off-by: Matt Evans <mattev@meta.com>
>> ---
>> drivers/vfio/pci/vfio_pci_core.c | 36 +++++++++++++++++++++++++++++++-
>> drivers/vfio/pci/vfio_pci_rdwr.c | 26 +++++++----------------
>> 2 files changed, 42 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
>> index 3f8d093aacf8..62931dc381d8 100644
>> --- a/drivers/vfio/pci/vfio_pci_core.c
>> +++ b/drivers/vfio/pci/vfio_pci_core.c
>> @@ -482,6 +482,39 @@ static int vfio_pci_core_runtime_resume(struct device *dev)
>> }
>> #endif /* CONFIG_PM */
>>
>> +/*
>> + * Eager-request BAR resources, and iomap them. Soft failures are
>> + * allowed, and consumers must check the barmap before use in order to
>> + * give compatible user-visible behaviour with the previous on-demand
>> + * allocation method.
>> + */
>> +static void vfio_pci_core_map_bars(struct vfio_pci_core_device *vdev)
>> +{
>> + struct pci_dev *pdev = vdev->pdev;
>> + int i;
>> +
>> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
>> + int bar = i + PCI_STD_RESOURCES;
>> +
>> + vdev->barmap[bar] = ERR_PTR(-ENODEV);
>> +
>> + if (!pci_resource_len(pdev, i))
>> + continue;
>> +
>> + if (pci_request_selected_regions(pdev, 1 << bar, "vfio")) {
>> + pci_dbg(vdev->pdev, "Failed to reserve region %d\n", bar);
>> + vdev->barmap[bar] = ERR_PTR(-EBUSY);
>> + continue;
>> + }
>> +
>> + vdev->barmap[bar] = pci_iomap(pdev, bar, 0);
>> + if (!vdev->barmap[bar]) {
>
> Sashiko notes[1] correctly that we need to release the requested region
> here.
>
> [1]https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260505173835.2324179-1-mattev@meta.com__;Iw!!Bt8RZUm9aw!75pHBGTcV8AYGiGGjzomqZLfDp7iR_j2JC6qCiJufoo7TxJTPuViQZjqp7I3ZRPPxwj1YtYSNQ$
Hnnng. Right, fixed.
-Matt
>> + pci_dbg(vdev->pdev, "Failed to iomap region %d\n", bar);
>> + vdev->barmap[bar] = ERR_PTR(-ENOMEM);
>> + }
>> + }
>> +}
>> +
>> /*
>> * The pci-driver core runtime PM routines always save the device state
>> * before going into suspended state. If the device is going into low power
>> @@ -568,6 +601,7 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
>> if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
>> vdev->has_vga = true;
>>
>> + vfio_pci_core_map_bars(vdev);
>>
>> return 0;
>>
>> @@ -648,7 +682,7 @@ void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
>>
>> for (i = 0; i < PCI_STD_NUM_BARS; i++) {
>> bar = i + PCI_STD_RESOURCES;
>> - if (!vdev->barmap[bar])
>> + if (IS_ERR_OR_NULL(vdev->barmap[bar]))
>> continue;
>> pci_iounmap(pdev, vdev->barmap[bar]);
>> pci_release_selected_regions(pdev, 1 << bar);
>> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
>> index 4251ee03e146..3bfbb879a005 100644
>> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
>> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
>> @@ -198,27 +198,15 @@ 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);
>>
>> +/*
>> + * The barmap is set up in vfio_pci_core_enable(). Callers use this
>> + * function to check that the BAR resources are requested or that the
>> + * pci_iomap() was done.
>> + */
>> int vfio_pci_core_setup_barmap(struct vfio_pci_core_device *vdev, int bar)
>> {
>> - struct pci_dev *pdev = vdev->pdev;
>> - int ret;
>> - void __iomem *io;
>> -
>> - if (vdev->barmap[bar])
>> - return 0;
>> -
>> - ret = pci_request_selected_regions(pdev, 1 << bar, "vfio");
>> - if (ret)
>> - return ret;
>> -
>> - io = pci_iomap(pdev, bar, 0);
>> - if (!io) {
>> - pci_release_selected_regions(pdev, 1 << bar);
>> - return -ENOMEM;
>> - }
>> -
>> - vdev->barmap[bar] = io;
>> -
>> + if (IS_ERR(vdev->barmap[bar]))
>> + return PTR_ERR(vdev->barmap[bar]);
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(vfio_pci_core_setup_barmap);
>
next prev parent reply other threads:[~2026-05-08 14:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 17:38 [PATCH v4 0/3] vfio/pci: Request resources and map BARs at enable time Matt Evans
2026-05-05 17:38 ` [PATCH v4 1/3] vfio/pci: Set up BAR resources and maps in vfio_pci_core_enable() Matt Evans
2026-05-07 22:21 ` Alex Williamson
2026-05-08 14:14 ` Matt Evans [this message]
2026-05-05 17:38 ` [PATCH v4 2/3] vfio/pci: Check BAR resources before exporting a DMABUF Matt Evans
2026-05-05 17:38 ` [PATCH v4 3/3] vfio/pci: Replace vfio_pci_core_setup_barmap() with vfio_pci_core_get_iomap() Matt Evans
2026-05-07 22:21 ` Alex Williamson
2026-05-08 15:30 ` Matt Evans
2026-05-08 17:45 ` Alex Williamson
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=339b4e0c-7c41-4585-83a3-a2cd9e7003ee@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox