drivers/vfio/pci/vfio_pci_core.c | 289 +++++++++++++++++++++++++++---- drivers/vfio/pci/vfio_pci_igd.c | 34 +++- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 24 +++ 4 files changed, 301 insertions(+), 47 deletions(-)
This RFC proposes a new uapi VFIO DEVICE_FEATURE to create per-region aliases with selectable attributes, initially enabling write-combine (WC) where supported by the underlying region. The goal is to expose a UAPI for userspace to request an alias of an existing VFIO region with extra flags, then interact with it via a stable alias index through existing ioctls and mmap where applicable. This proposal is following Alex's suggestion [1]. This uapi allows creating a region alias where the user could specify to enable certain attributes through the alias. And then could use the alias index to get the region info and grab the offset to operate on. One example is to create a new Alias for bar 0 or similar BAR with WC enabled. Then you can use the alias offset to mmap to the region with WC enabled. The uapi allows the user to request a region index to alias and the extra flags to be set. Users can PROBE to get which flags are supported by this region. The flags are the same to the region flags in the region_info uapi. This adds two new region flags: - VFIO_REGION_INFO_FLAG_ALIAS: set on alias regions. - VFIO_REGION_INFO_FLAG_WC: indicates WC is in effect for that region. Then this series implement this uapi on vfio-pci. For vfio-pci, Alias regions are only (for now) possible for mmap supported regions. There could be future usages for these alias regions other than mmaps (like I think we could use it to also allow to use read & write on pci_iomap_wc version of the region?). In case if similar alias region already exist return the current alias index to the user. To mmap the region alias, we use the mmap region ops. Through that we translate the vm_pgoff to its aliased region and call vfio_device mmap with the alias pgoff. This enables us to mmap the original region then update the pgrot for WC afterwards. The call path would be: vfio_pci_core_mmap (index >= VFIO_PCI_NUM_REGIONS) vfio_pci_alias_region_mmap (update vm_pgoff) vfio_pci_core_mmap This series also adds required locking for region array accessing. Since now regions are added after initial setup. [1]: https://lore.kernel.org/kvm/20250811160710.174ca708.alex.williamson@redhat.com/ references: https://lore.kernel.org/kvm/20250804104012.87915-1-mngyadam@amazon.de/ https://lore.kernel.org/kvm/20240731155352.3973857-1-kbusch@meta.com/ https://lore.kernel.org/kvm/lrkyq4ivccb6x.fsf@dev-dsk-mngyadam-1c-cb3f7548.eu-west-1.amazon.com/ Mahmoud Adam (7): vfio/pci: refactor region dereferences for RCU. vfio_pci_core: split krealloc to allow use RCU & return index vfio/pci: add RCU locking for regions access vfio: add FEATURE_ALIAS_REGION uapi vfio_pci_core: allow regions with no release op vfio-pci: add alias_region mmap ops vfio-pci-core: implement FEATURE_ALIAS_REGION uapi drivers/vfio/pci/vfio_pci_core.c | 289 +++++++++++++++++++++++++++---- drivers/vfio/pci/vfio_pci_igd.c | 34 +++- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 24 +++ 4 files changed, 301 insertions(+), 47 deletions(-) -- 2.47.3 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
On Wed, Sep 24, 2025 at 7:11 AM Mahmoud Adam <mngyadam@amazon.de> wrote: > > This RFC proposes a new uapi VFIO DEVICE_FEATURE to create per-region > aliases with selectable attributes, initially enabling write-combine > (WC) where supported by the underlying region. The goal is to expose a > UAPI for userspace to request an alias of an existing VFIO region with > extra flags, then interact with it via a stable alias index through > existing ioctls and mmap where applicable. Would it make sense to build this on top of Leon's dma-buf series [1]? My understanding is that dma-buf can support mmap, so WC could just be a property attached to a dma-buf fd and passed by userspace via VFIO_DEVICE_FEATURE_DMA_BUF. Then VFIO wouldn't have to create or manage region aliases. Apologies if this has already been discussed, I did not go through all the past discussion. [1] https://lore.kernel.org/kvm/72ecaa13864ca346797e342d23a7929562788148.1760368250.git.leon@kernel.org/
David Matlack <dmatlack@google.com> writes: > On Wed, Sep 24, 2025 at 7:11 AM Mahmoud Adam <mngyadam@amazon.de> wrote: >> >> This RFC proposes a new uapi VFIO DEVICE_FEATURE to create per-region >> aliases with selectable attributes, initially enabling write-combine >> (WC) where supported by the underlying region. The goal is to expose a >> UAPI for userspace to request an alias of an existing VFIO region with >> extra flags, then interact with it via a stable alias index through >> existing ioctls and mmap where applicable. > > Would it make sense to build this on top of Leon's dma-buf series [1]? > My understanding is that dma-buf can support mmap, so WC could just be > a property attached to a dma-buf fd and passed by userspace via > VFIO_DEVICE_FEATURE_DMA_BUF. Then VFIO wouldn't have to create or > manage region aliases. > The motivation for this proposal is that it would integrate seamlessly with DPDK. I haven’t yet investigated the new dma-buf series as a solution, but my initial impression is that it doesn’t fit well with DPDK’s existing model. Enabling write-combine with dma-buf was also proposed here[1] and I agree that’s a generally good idea and fits naturally with dma-buf. I think it would be valuable to support WC with both region aliasing and dma-buf, But maybe Alex have a different opinion on that. [1]: https://lore.kernel.org/kvm/20250918214425.2677057-1-amastro@fb.com/ > Apologies if this has already been discussed, I did not go through all > the past discussion. > > [1] https://lore.kernel.org/kvm/72ecaa13864ca346797e342d23a7929562788148.1760368250.git.leon@kernel.org/ Thanks, MNAdam Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
On Wed, 24 Sep 2025 16:09:51 +0200 Mahmoud Adam <mngyadam@amazon.de> wrote: > This RFC proposes a new uapi VFIO DEVICE_FEATURE to create per-region > aliases with selectable attributes, initially enabling write-combine > (WC) where supported by the underlying region. The goal is to expose a > UAPI for userspace to request an alias of an existing VFIO region with > extra flags, then interact with it via a stable alias index through > existing ioctls and mmap where applicable. > > This proposal is following Alex's suggestion [1]. This uapi allows > creating a region alias where the user could specify to enable certain > attributes through the alias. And then could use the alias index to > get the region info and grab the offset to operate on. > > One example is to create a new Alias for bar 0 or similar BAR with WC > enabled. Then you can use the alias offset to mmap to the region with > WC enabled. > > The uapi allows the user to request a region index to alias and the > extra flags to be set. Users can PROBE to get which flags are > supported by this region. The flags are the same to the region flags > in the region_info uapi. > > This adds two new region flags: > - VFIO_REGION_INFO_FLAG_ALIAS: set on alias regions. > - VFIO_REGION_INFO_FLAG_WC: indicates WC is in effect for that region. Sorry for the delayed feedback... I think these should be described via capabilities returned with the vfio_region_info rather than flags. A flag that indicates the region is an alias is really only useful for the restriction that we don't want to allow aliases of aliases, but it doesn't provide full introspection of what region this is actually an alias of. The WC flag also doesn't allow much extension. I think we want this to have natural room to implement further mapping flags, so likely the same capability that describes the region as being an alias should also report back the mapping flags for the alias. Thanks, Alex > > Then this series implement this uapi on vfio-pci. For vfio-pci, Alias > regions are only (for now) possible for mmap supported regions. There > could be future usages for these alias regions other than mmaps (like > I think we could use it to also allow to use read & write on > pci_iomap_wc version of the region?). In case if similar alias region > already exist return the current alias index to the user. > > To mmap the region alias, we use the mmap region ops. Through that we > translate the vm_pgoff to its aliased region and call vfio_device mmap > with the alias pgoff. This enables us to mmap the original region then > update the pgrot for WC afterwards. > > The call path would be: > vfio_pci_core_mmap (index >= VFIO_PCI_NUM_REGIONS) > vfio_pci_alias_region_mmap (update vm_pgoff) > vfio_pci_core_mmap > > This series also adds required locking for region array > accessing. Since now regions are added after initial setup. > > [1]: https://lore.kernel.org/kvm/20250811160710.174ca708.alex.williamson@redhat.com/ > > references: > https://lore.kernel.org/kvm/20250804104012.87915-1-mngyadam@amazon.de/ > https://lore.kernel.org/kvm/20240731155352.3973857-1-kbusch@meta.com/ > https://lore.kernel.org/kvm/lrkyq4ivccb6x.fsf@dev-dsk-mngyadam-1c-cb3f7548.eu-west-1.amazon.com/ > > Mahmoud Adam (7): > vfio/pci: refactor region dereferences for RCU. > vfio_pci_core: split krealloc to allow use RCU & return index > vfio/pci: add RCU locking for regions access > vfio: add FEATURE_ALIAS_REGION uapi > vfio_pci_core: allow regions with no release op > vfio-pci: add alias_region mmap ops > vfio-pci-core: implement FEATURE_ALIAS_REGION uapi > > drivers/vfio/pci/vfio_pci_core.c | 289 +++++++++++++++++++++++++++---- > drivers/vfio/pci/vfio_pci_igd.c | 34 +++- > include/linux/vfio_pci_core.h | 1 + > include/uapi/linux/vfio.h | 24 +++ > 4 files changed, 301 insertions(+), 47 deletions(-) >
On Wed, Sep 24, 2025 at 7:11 AM Mahmoud Adam <mngyadam@amazon.de> wrote: > > This adds two new region flags: > - VFIO_REGION_INFO_FLAG_ALIAS: set on alias regions. > - VFIO_REGION_INFO_FLAG_WC: indicates WC is in effect for that region. Once you settle on a uAPI, this would be a good candidate for some VFIO selftests coverage [1][2]. Assuming the uAPI supports setting up equivalent aliases of BARs, you can use the VFIO selftests driver framework to drive some meaningful usage of the aliases. For example, you could write a test that overrides bars[n].vaddr in struct vfio_pci_device to force the drivers to use aliased BARs that you set up and mmapped, and make sure the device can still perform memcpys as it should afterward. But regardless, there is still plenty of opportunity for sanity tests that verify the new ioctls fail and succeed when they should, and that mmap works as expected. Meaningfully verifying that VFIO_REGION_INFO_FLAG_WC is being applied correctly might be a challenge. [1] https://lore.kernel.org/kvm/20250822212518.4156428-1-dmatlack@google.com/ [2] https://lore.kernel.org/kvm/20250930124221.39523455.alex.williamson@redhat.com/
David Matlack <dmatlack@google.com> writes: > On Wed, Sep 24, 2025 at 7:11 AM Mahmoud Adam <mngyadam@amazon.de> wrote: >> >> This adds two new region flags: >> - VFIO_REGION_INFO_FLAG_ALIAS: set on alias regions. >> - VFIO_REGION_INFO_FLAG_WC: indicates WC is in effect for that region. > > Once you settle on a uAPI, this would be a good candidate for some > VFIO selftests coverage [1][2]. Yup, I was planning to do that after seeing the new addition of vfio selftests. I have already a small test that I use for testing this. I can clean it up & port it to fit in the vfio selftest, once there is some momentum on this series. Thanks David. -MNAdam Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
© 2016 - 2026 Red Hat, Inc.