On Fri, 31 Jul 2026 15:01:01 -0700 Bobby Eshleman wrote:
> Meanwhile, do we want drivers/net/hw/config to workaround by carrying
> something like SYNC_FILE or DMABUF_HEAPS, or wait and see about the
> udmabuf kconfig change?
Let's enable SYNC_FILE for now and pursue the UDMABUF change in
parallel. It will land in another tree if at all, so we'll have
to wait a while before it propagates to us.
Hi Praan,
On 30/07/2026 23:55, Pranjal Shrivastava wrote:
> On Wed, Jul 15, 2026 at 06:47:26PM +0100, Matt Evans wrote:
>> Add vfio_pci_dma_buf_find_pfn(), which a VMA fault handler can use to
>> find a PFN.
>>
>> This supports multi-range DMABUFs, which typically would be used to
>> represent scattered spans but might even represent overlapping or
>> aliasing spans of PFNs.
>>
>> Because this is intended to be used in vfio_pci_core.c, we also need
>> to expose the struct vfio_pci_dma_buf in the vfio_pci_priv.h header.
>>
>> Signed-off-by: Matt Evans <matt(a)ozlabs.org>
>> ---
>> drivers/vfio/pci/vfio_pci_dmabuf.c | 153 ++++++++++++++++++++++++++---
>> drivers/vfio/pci/vfio_pci_priv.h | 20 ++++
>> 2 files changed, 160 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
>> index c16f460c01d6..7c047400dfd1 100644
>> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
>> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
>> @@ -9,19 +9,6 @@
>>
>> MODULE_IMPORT_NS("DMA_BUF");
>>
>> -struct vfio_pci_dma_buf {
>> - struct dma_buf *dmabuf;
>> - struct vfio_pci_core_device *vdev;
>> - struct list_head dmabufs_elm;
>> - size_t size;
>> - struct phys_vec *phys_vec;
>> - struct p2pdma_provider *provider;
>> - u32 nr_ranges;
>> - struct kref kref;
>> - struct completion comp;
>> - u8 revoked : 1;
>> -};
>> -
>> static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
>> struct dma_buf_attachment *attachment)
>> {
>> @@ -106,6 +93,146 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
>> .release = vfio_pci_dma_buf_release,
>> };
>>
>> +int vfio_pci_dma_buf_find_pfn(struct vfio_pci_dma_buf *priv,
>> + struct vm_area_struct *vma,
>> + unsigned long fault_addr,
>> + unsigned int order,
>> + unsigned long *out_pfn)
>> +{
>> + /*
>> + * Given a VMA (start, end, pgoffs) and a fault address,
>> + * search the corresponding DMABUF's phys_vec[] to find the
>> + * range representing the address's offset into the VMA, and
>> + * its PFN.
>> + *
>> + * The phys_vec[] ranges represent contiguous spans of VAs
>> + * upwards from the buffer offset 0; the actual PFNs might be
>> + * in any order, overlap/alias, etc. Calculate an offset of
>> + * the desired page given VMA start/pgoff and address, then
>> + * search upwards from 0 to find which span contains it.
>> + *
>> + * On success, a valid PFN for a page sized by 'order' is
>> + * returned into out_pfn.
>> + *
>> + * Failure occurs if:
>> + * - A hugepage would cross the edge of the VMA,
>> + * - A hugepage isn't entirely contained within a range
>> + * (including where it straddles the boundary between
>> + * ranges),
>> + * - We find a range, but the final PFN isn't aligned to the
>> + * requested order.
>> + *
>> + * Upon failure, -EAGAIN is returned and the caller is
>> + * expected to try again with a smaller order, which will
>> + * eventually succeed (order=0 will always work).
>> + *
>> + * It's suboptimal if DMABUFs are created with neighbouring
>> + * ranges that are physically contiguous, since hugepages
>> + * can't straddle range boundaries. (The construction of the
>> + * ranges should merge them in this case.)
>> + *
>> + * Finally, vma_pgoff_adjust is used with a DMABUF created for
>> + * a VFIO BAR mmap: a BAR mapped with vm_pgoff > 0 creates a
>> + * DMABUF such that byte 0 of the VMA corresponds to byte 0 of
>> + * the DMABUF and byte 'vm_pgoff << PAGE_SHIFT' into the BAR.
>> + * To avoid double-offsetting in this scenario, subtracting
>> + * vma_pgoff_adjust from this (non-zero) vm_pgoff generates
>> + * the effective offset.
>> + */
>> +
>> + const unsigned long pagesize = PAGE_SIZE << order;
>> + unsigned long vma_off = ((vma->vm_pgoff - priv->vma_pgoff_adjust) <<
>> + PAGE_SHIFT) & VFIO_PCI_OFFSET_MASK;
>
> Maybe I'm getting ahead of myself here.. but it seems like this
> restricts us to only mapping DMABUFs at offsets < 1TB due to the
> VFIO_PCI_OFFSET_MASK (since we have HBMs on PCI devices now, hitting 1TB
> may not be a very distant future).
This is a really good question, thanks for raisiing it. It is not too
forward-thinking at all.
> While I understand this mask is needed to drop the BAR encoding in the
> high bits.
>
> My worry is, if in the future a user were to export a massive
> contiguous DMABUF (e.g., >1TB of aggregated HBM) and tried to mmap deep
> into it (passing an offset >= 1TB), this bitwise AND would silently drop
> the high bits, leading to silent data corruption.
One of the big advantages of DMABUF export was that the range could be
huge and unencumbered by the VFIO_PCI_OFFSET_SHIFT of the traditional
mmap() interface. It's a way to mmap huge BARs without having to change
the user-visible shift). So definitely this is a relevant concern.
> I think we should explicitly reject such an mmap with -EINVAL like:
>
> +const unsigned long pagesize = PAGE_SIZE << order;
> +unsigned long vma_off = (vma->vm_pgoff - priv->vma_pgoff_adjust) << PAGE_SHIFT;
>
> +/*
> + * Prevent silent wrap-around if the user mmaps a DMABUF at an
> + * offset greater than the VFIO index mask allows.
> + */
> +if (unlikely(vma_off > VFIO_PCI_OFFSET_MASK))
> + return -EINVAL;
>
> +vma_off &= VFIO_PCI_OFFSET_MASK;
Agreed, for now this absolutely should not silently wrap if the offset
is > 1TB, and we live with the restriction that a DMABUF sized >1TB
can't be mapped with such an offset. (We can still, say, map all of a
16TB DMABUF with offset=0, which is good.). I'll add a check, thanks
for pointing this out.
I suggest as something to revisit later, we flag for a DMABUF (maybe an
evolution of vma_pgoff_adjust) to differentiate whether this masking
needs to be applied (traditional mmap() path) or not (DMABUF mmap()),
and then offsets can be arbitrarily large.
Cheers,
Matt
>> + unsigned long rounded_page_addr = ALIGN_DOWN(fault_addr, pagesize);
>> + unsigned long rounded_page_end = rounded_page_addr + pagesize;
>> + unsigned long fault_offset;
>> + unsigned long fault_offset_end;
>> + unsigned long range_start_offset = 0;
>> + unsigned int i;
>> + int ret;
>> +
>
>
> Thanks,
> Praan
On Wed, Jul 29, 2026 at 11:27 PM Baineng Shou <shoubaineng(a)gmail.com> wrote:
>
> Add a test case that verifies no file descriptor is leaked when
> DMA_HEAP_IOCTL_ALLOC succeeds internally but copy_to_user() fails
> to deliver the fd number back to userspace.
>
> The failure is triggered by placing the ioctl argument in a private
> anonymous page and flipping it to PROT_READ (via mprotect) between
> the kernel's copy_from_user() and copy_to_user() calls. With the
> buggy kernel the ioctl returns -EFAULT but leaves an extra open fd
> in the process's fd table; with the fixed kernel the fd count is
> unchanged.
>
> This serves as a regression test for:
> "dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds"
>
> Suggested-by: Sumit Semwal <sumit.semwal(a)linaro.org>
> Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com>
> ---
> .../selftests/dmabuf-heaps/dmabuf-heap.c | 115 +++++++++++++++++-
> 1 file changed, 114 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> index fc9694fc4e89..bd58e5b06c8b 100644
> --- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> @@ -390,6 +390,118 @@ static void test_alloc_errors(char *heap_name)
> close(heap_fd);
> }
>
> +/*
> + * test_alloc_no_fd_leak_on_efault - verify no fd is leaked when
> + * copy_to_user() fails during DMA_HEAP_IOCTL_ALLOC.
> + *
> + * The bug: dma_buf_fd() called fd_install() before copy_to_user().
> + * If copy_to_user() then failed (e.g. via mprotect), the fd was
> + * silently installed in the fd table but never returned to userspace.
> + *
> + * The fix: reserve the fd with get_unused_fd_flags() first, attempt
> + * copy_to_user(), and only call fd_install() on success.
> + *
> + * We trigger the failure by placing the ioctl argument in a page,
> + * flipping it to PROT_READ between copy_from_user and copy_to_user,
> + * and counting open file descriptors before and after.
> + */
> +static void test_alloc_no_fd_leak_on_efault(char *heap_name)
> +{
> + int heap_fd = -1;
> + int fd_before, fd_after;
> + int ret;
> + long page_size;
> + struct dma_heap_allocation_data *req;
> +
> + ksft_print_msg("Testing no fd leak when copy_to_user() fails:\n");
> +
> + heap_fd = dmabuf_heap_open(heap_name);
> +
> + page_size = sysconf(_SC_PAGESIZE);
> +
> + /*
> + * Place the ioctl argument in its own private anonymous page so
> + * we can flip its protection independently.
> + */
> + req = mmap(NULL, page_size, PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> + if (req == MAP_FAILED) {
> + ksft_test_result_fail("mmap failed: %s\n", strerror(errno));
> + goto out;
> + }
> +
> + memset(req, 0, sizeof(*req));
> + req->len = page_size;
> + req->fd_flags = O_RDWR | O_CLOEXEC;
> +
> + /* Count open fds before the ioctl */
> + fd_before = 0;
> + {
> + DIR *d = opendir("/proc/self/fd");
> + struct dirent *de;
> +
> + if (!d) {
> + ksft_test_result_fail("opendir /proc/self/fd: %s\n",
> + strerror(errno));
> + munmap(req, page_size);
> + goto out;
> + }
> + while ((de = readdir(d)))
> + if (de->d_name[0] != '.')
> + fd_before++;
> + closedir(d);
> + /* subtract the fd opened by opendir itself */
But no actual subtraction?
> + }
> +
> + /*
> + * Make the page read-only: copy_from_user() in the kernel will
> + * still succeed (it already ran),
Huh? copy_from_user hasn't run yet. That happens inside the ioctl().
> but copy_to_user() that writes
> + * the fd number back will fault.
> + */
> + mprotect(req, page_size, PROT_READ);
> +
> + ret = ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, req);
> +
> + /* Re-allow writes so munmap can clean up */
> + mprotect(req, page_size, PROT_READ | PROT_WRITE);
> + munmap(req, page_size);
> +
> + if (ret != -1 || errno != EFAULT) {
This looks like you meant &&, but I think we should just fail if ret
!= -1. Either the mprotect is broken, or dma-heap didn't actually try
to copy_to_user.
> + /*
> + * If the ioctl didn't fail with EFAULT, either the kernel
> + * handled it differently or mprotect raced.
mprotect is synchronous, how could it race with anything here?
> Skip rather
> + * than giving a false pass/fail.
> + */
> + ksft_test_result_skip(
> + "ioctl did not return EFAULT (ret=%d errno=%d), skipping\n",
> + ret, errno);
> + goto out;
> + }
> +
> + /* Count open fds after the failed ioctl */
> + fd_after = 0;
> + {
> + DIR *d = opendir("/proc/self/fd");
> + struct dirent *de;
> +
> + if (!d) {
> + ksft_test_result_fail("opendir /proc/self/fd: %s\n",
> + strerror(errno));
> + goto out;
> + }
> + while ((de = readdir(d)))
> + if (de->d_name[0] != '.')
> + fd_after++;
> + closedir(d);
> + }
> +
> + ksft_test_result(fd_before == fd_after,
> + "no fd leak on EFAULT: before=%d after=%d\n",
This is for the failure case, so I don't think the "no" should be in the string.
> + fd_before, fd_after);
> +out:
> + close(heap_fd);
> +}
> +
> static int numer_of_heaps(void)
> {
> DIR *d = opendir(DEVPATH);
> @@ -420,7 +532,7 @@ int main(void)
> return KSFT_SKIP;
> }
>
> - ksft_set_plan(11 * numer_of_heaps());
> + ksft_set_plan(12 * numer_of_heaps());
>
> while ((dir = readdir(d))) {
> if (!strncmp(dir->d_name, ".", 2))
> @@ -435,6 +547,7 @@ int main(void)
> test_alloc_zeroed(dir->d_name, ONE_MEG);
> test_alloc_compat(dir->d_name);
> test_alloc_errors(dir->d_name);
> + test_alloc_no_fd_leak_on_efault(dir->d_name);
> }
> closedir(d);
>
> --
> 2.34.1
>
The strongest cybersecurity strategy isn't measured by how a company responds after an attack—it's measured by how well it prepares before one ever happens. Every day, organizations and individuals face phishing campaigns, ransomware, credential theft, and other cyber threats. While no security program can eliminate every risk, preparation can significantly reduce the likelihood and impact of an incident.
Many people believe cyberattacks only target large corporations. In reality, small businesses, freelancers, cryptocurrency investors, and private individuals are frequently targeted because attackers assume they may have fewer security controls in place. A single compromised password or overlooked software update can provide an opportunity for unauthorized access.
At **MUYERN TRUST**, we help clients understand their digital risks through cybersecurity consulting, digital forensics, blockchain investigations, cloud security, and incident response services. Information about our professional services is available at (http://www.muyerntrust.com), and confidential inquiries can also be sent to (muyerntrusted((a))mail-me(.)c o m)
One of the most valuable investments any organization can make is a security assessment. Understanding where weaknesses exist allows those issues to be addressed before they become security incidents. Regular reviews of authentication methods, backup procedures, employee awareness, and network security often reveal opportunities for improvement that might otherwise go unnoticed.
Another overlooked aspect of cybersecurity is documentation. Knowing how systems are configured, where important information is stored, and who is responsible for responding during an incident helps reduce confusion when time matters most. A well-prepared response plan can often limit disruption and support a faster recovery.
Technology continues to evolve rapidly, but the fundamentals remain the same. Strong passwords, multi-factor authentication, software updates, encrypted backups, and user awareness continue to provide meaningful protection against many common threats. These practices may appear simple, yet they remain among the most effective security measures available.
Cybersecurity is not only about protecting computers—it is about protecting people, businesses, and the information they depend on every day. Building a culture of security awareness is an ongoing process that benefits everyone connected to an organization.
At MUYERN TRUST, we are committed to providing professional cybersecurity services backed by careful analysis, ethical practices, and practical solutions. Whether assisting with a cybersecurity incident, conducting a blockchain investigation, or helping improve an organization's security posture, our focus remains the same: delivering reliable technical expertise with professionalism and integrity.
**Whats App:** +1 2.0.2 7.0.3 2.2.3.9
https://drifthuntersonline.io
Drift Hunters is an immersive drifting game that puts players behind the wheel of powerful sports cars on a variety of detailed tracks. Instead of simply racing to the finish, the challenge comes from maintaining long, controlled drifts, earning points, and mastering each corner with precise steering and throttle control. Every successful run rewards practice, making the driving feel both satisfying and skill-based.
Beyond its realistic driving physics, Drift Hunters features a wide selection of customizable vehicles, performance upgrades, and visually appealing environments that keep each session fresh. Players can fine-tune their cars, experiment with different setups
On Thu, 30 Jul 2026 14:39:37 -0700 Bobby Eshleman wrote:
> Poking around, it looks like 231.1.167.0 and above should support
> everything, so fw should be okay AFAICT.
>
> Looks like the config is missing CONFIG_NET_DEVMEM and CONFIG_UDMABUF?
Ah, damn, you're right. I grepped for DEVMEM and didn't look closely on
a hit. Turns out there's a non-NET DEVMEM, too.
Could you send a patch to add the missing config options to
tools/testing/selftests/drivers/net/hw/config ?
Can be separate or part of this series, doesn't matter.
> Sorry, took me a while... was certain it was a bug in my code.
>
> Not the failure here, but wondering if this was on ARM led to seeing
> that 16K hardcoded rx_page_size in run_rx_large_niov() may fail on ARM
> with 64K pages because it will fail the IS_ALIGN(16K, 64K) check...
Ah, good thought. We've been meaning to get an ARM64 server for NIPA
(our current server supplier is out). If it's not too hard could be nice
to guard against that. But also not a huge deal for HW tests if they
fail instead of skipping.
Hi all,
The goal of this series is to enable userspace driver designs that use
VFIO to export DMABUFs representing subsets of PCI device BARs, and
"vend" those buffers from a primary process to other subordinate
processes by fd. These processes then mmap() the buffers and their
access to the device is isolated to the exported ranges. This is an
improvement on sharing the VFIO device fd to subordinate processes,
which would allow unfettered access.
This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd
to subordinate processes. Second, a new revocation mechanism is added
to allow the primary process to forcibly revoke access to
previously-shared BAR spans, even if the subordinate processes haven't
cleanly exited.
(The related topic of safe delegation of iommufd control to the
subordinate processes is not addressed here, and is follow-up work.)
The background/rationale is covered in more detail in the RFC cover
letters.
Feedback from the RFCs requested that, instead of creating
DMABUF-specific vm_ops and .fault paths, to go the whole way and
migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too,
resulting in a common vm_ops and fault handler for mmap()s of both the
VFIO device and explicitly-exported DMABUFs. This will help future
iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get
a DMABUF for a VFIO BAR as a DMA target.
mmap() conversion to use DMABUF underneath has been done for vfio-pci,
but not sub-drivers:
nvgrace-gpu's mmap() override path is unchanged; I kept this out of
scope for now not least because I don't have a thorough test setup
for this system. I would prefer to help the nvgrace-gpu maintainers
enable BAR mmap() DMABUFs themselves.
Notes on patches
================
PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release()
PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
Later in the series, vfio-pci's mmap() is going to depend on
pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which
in turn depended on ZONE_DEVICE. That isn't available on 32-bit
and some archs, because they lack MEMORY_HOTPLUG and friends.
VFIO does _not_ require actual P2P to be present for basic mmap()
functionality, only for the optional CONFIG_DMA_SHARED_BUFFER
feature.
These split out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which
currently contains pcim_p2pdma_provider()), and an optional
CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing
P2P functionality in the existing p2pdma.c. The first splits
out pool cleanup from the release path, and the second does the
refactor/code move to the new file.
vfio/pci: Add a helper to look up PFNs for DMABUFs
vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA
The first adds a DMABUF VMA fault handler helper to determine
arbitrary-sized PFNs from ranges in DMABUF. The second refactors
DMABUF export for use by the existing export feature, and adds a
helper that creates a DMABUF corresponding to a VFIO BAR mmap()
request.
vfio/pci: Convert BAR mmap() to use a DMABUF
The vfio-pci core mmap() creates a DMABUF with the helper above,
and the vm_ops fault handler uses the other helper to resolve the
fault. Because this depends on DMABUF structs/code,
CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER.
The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export
support code.
NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file
becomes that of the DMABUF. The DMABUF takes ownership of the
device file and put()s it on release, which maintains the existing
behaviour of a VMA keeping the VFIO device open.
BAR zapping then happens via the existing vfio_pci_dma_buf_move()
path, which now needs to unmap PTEs in the DMABUF's address_space.
vfio/pci: Provide a user-facing name for BAR mappings
There was a request for decent debug naming in /proc/<pid>/maps
etc. comparable to the existing VFIO names: since the VMAs are
DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical
to before. This is a user-visible change, but this patch at least
now gives us extra info on the BDF & BAR being mapped.
vfio/pci: Clean up BAR zap and revocation
In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete,
since it unmaps PTEs in the VFIO device address_space which is now
unused. This consolidates all calls (e.g. around reset) with the
neighbouring vfio_pci_dma_buf_move()s into new functions, to
revoke/unrevoke (making the steps clearer).
NOTE: Because drivers can use their own vm_ops and override .mmap,
the core must conservatively assume an overridden .mmap might still
add PTEs to the VFIO device address_space and therefore still does
the zap. A new flag, zap_bars_on_revoke, enables the zap when
.mmap is overridden. A driver that does not need the zap can clear
this to opt-out, e.g. if the driver calls down to the common mmap
(and so uses DMABUFs). hisi-acc-vfio-pci does just this, and thus
sets the opt-out flag.
vfio/pci: Support mmap() of a VFIO DMABUF
Adds mmap() for a DMABUF fd exported from vfio-pci.
It was a goal to keep the VFIO device fd lifetime behaviour
unchanged with respect to the DMABUFs. An application can close
all device fds, and this will revoke/clean up all DMABUFs; then, no
mappings or other access can be performed. When enabling mmap() of
the DMABUFs, this means access through the VMA is also revoked.
This complicates the fault handler because whilst the DMABUF
exists, it has no guarantee that the corresponding VFIO device is
still alive. Adds synchronisation ensuring the vdev is available
before vdev->memory_lock is touched; this holds the device
registration so that even if the buffer has been cleaned up, vdev
hasn't been freed and so the lock can be safely taken.
vfio/pci: Permanently revoke a DMABUF on request
This is mostly a rename of `revoked` to an enum, `status`, and
adding a third state for a buffer: usable, revoked temporary,
revoked permanent. A new VFIO feature is added,
VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported
from the same device) and permanently revokes it. Thus a userspace
driver can guarantee any downstream consumers of a shared fd are
prevented from accessing a BAR range, and that range can be reused.
NOTE: This might block userspace, waiting on importers to detach.
The code doing revocation in vfio_pci_dma_buf_move() is moved, to a
common function for use by ..._move() and this new feature.
NOTE: See changelog, by request v4 added a condition to the
existing code to elide the unnecessary invalidation/sync on the
un-revoke path.)
NOTE: Previous versions contained an additional feature patch,
"vfio/pci: Add mmap() attributes to DMABUF feature". This has been
dropped in v5 because:
- The mechanism simply set vma->vm_page_prot. This would be
sufficient for arm64 and other architectures.
- However, (locally-run claude-opus-4-8) Sashiko flagged that, on
x86, additional memtype handling is required to set up the PAT.
Without this, the memtype is returned back to UC- by
pfnmap_setup_cachemode() upon PTE creation.
Most other sources of userspace WC mappings create PTEs eagerly with
e.g. io_remap_pfn_range() which memtype_reserve() WC for the range.
Getting them with lazy-fault used by vfio-pci is more complicated
(e.g. perhaps registering WC for BARs with PAT/MTRRs, and deciding how
to deal with aliasing...). Since this feature is not critical for
this series to be useful, I've decided for now to drop it in favour of
a simpler series now and revisiting this separ*ately.
Testing
=======
(The [RFC ONLY] userspace test program, for QEMU edu-plus, can be
found in the GitHub branch below. It at least illustrates how the
export, map, revoke, and close semantics interoperate.)
This code has been tested in mapping DMABUFs of single/multiple ranges
from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs,
vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage
mappings. No regressions observed on the VFIO selftests, or on our
internal vfio-pci applications. VFIO on i386 has been build-tested.
Dear Reviewers,
===============
I was grateful for the reviews and Reviewed-Bys on previous versions.
Thanks; I've added some Reviewed-Bys/Acks. I have NOT included your
tags where the patch has materially changed after your review (or
where requested changes ended up more than super-trivial). I hope
that's okay.
End
===
This is based on v7.2-rc3.
These commits are on GitHub for easier browsing, along with
"[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test":
https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mma…
Thanks for reading,
Matt
================================================================================
Changelog:
v5:
- Rebased on 7.2-rc3
- Dropped the memattr/WC feature (see explanation above).
- "vfio/pci: Convert BAR mmap() to use a DMABUF": Fixed a
potentially-nasty bug (which (locally-run) Sashiko found!) whereby
the unmap_mapping_range() performed in cleanup was passed a range
up from offset zero for the DMABUF size. Initially this was how
all DMABUFs were created and an appropriate zap, but a new version
kept the VFIO region index encoded in the offset -- for BAR > 0 the
unmap span would then mismatch. Instead, pass size 0 to mean an
"all" range. Because the goal is to shoot down everything relating
to one DMABUF and the address_space can only contain things
relating to that DMABUF, this is equivalent and has the bonus of
never failing to match mappings...
Praan, Kevin, I kept your R-Bs on this fix.
- The revoke patch converts vfio_pci_dma_buf_cleanup()'s priv->vdev =
NULL to a WRITE_ONCE, corresponding to the revoke function's
READ_ONCE (performed to test that the VFIO and DMABUF are related).
- Clarified the VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE UAPI comments,
documenting previously-missing error cases and their reasons.
v4: https://lore.kernel.org/all/20260701171245.90111-1-matt@ozlabs.org/
v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/
v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/
v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/
RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/
RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/
Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/
Matt Evans (9):
PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release()
PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
vfio/pci: Add a helper to look up PFNs for DMABUFs
vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA
vfio/pci: Convert BAR mmap() to use a DMABUF
vfio/pci: Provide a user-facing name for BAR mappings
vfio/pci: Clean up BAR zap and revocation
vfio/pci: Support mmap() of a VFIO DMABUF
vfio/pci: Permanently revoke a DMABUF on request
MAINTAINERS | 2 +-
drivers/pci/Kconfig | 5 +
drivers/pci/Makefile | 1 +
drivers/pci/p2pdma.c | 113 +---
drivers/pci/p2pdma.h | 29 +
drivers/pci/p2pdma_core.c | 122 +++++
drivers/vfio/pci/Kconfig | 5 +-
drivers/vfio/pci/Makefile | 3 +-
.../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 +
drivers/vfio/pci/vfio_pci_config.c | 30 +-
drivers/vfio/pci/vfio_pci_core.c | 210 +++++--
drivers/vfio/pci/vfio_pci_dmabuf.c | 515 +++++++++++++++---
drivers/vfio/pci/vfio_pci_priv.h | 53 +-
include/linux/pci-p2pdma.h | 24 +-
include/linux/pci.h | 2 +-
include/linux/vfio_pci_core.h | 1 +
include/uapi/linux/vfio.h | 25 +
17 files changed, 875 insertions(+), 273 deletions(-)
create mode 100644 drivers/pci/p2pdma.h
create mode 100644 drivers/pci/p2pdma_core.c
--
2.50.1 (Apple Git-155)
+97158 994 3206} Abortion Pills in Dubai | Abu Dhabi | Sharjah
Whatsapp +97158 994 3206
We have Abortion Pills / Cytotec Tablets /mifegest kit Available in Dubai,
Sharjah, Abudhabi, Ajman, Alain, Fujairah, Ras Al Khaimah, Umm Al Quwain,
UAE, buy cytotec in Dubai
+97158 994 3206 “”Abortion Pills near me DUBAI | ABU DHABI|UAE. Price of
Misoprostol, Cytotec”
+97158 994 3206 Dr.Leen “BUY ABORTION PILLS MIFEGEST KIT, MISOPROTONE,
CYTOTEC PILLS IN DUBAI, ABU DHABI,UAE” Contact me now via whatsapp……
abortion Pills Cytotec also available Oman Qatar Doha Saudi Arabia Bahrain
Above all, Cytotec Abortion Pills are Available In Dubai / UAE, you will be
very happy to do abortion in dubai
Buy abortion pills in Dubai Buy abortion pills in Oman Buy abortion pills
in Abu Dhabi Buy abortion pills in Sharjah Fujairah Buy abortion pills in
Ras Al Khaimah (RAK) Buy abortion pills in Ajman Buy abortion pills in Al
Ain Buy abortion pills in Umm Al Quwain (UAQ) Buy abortion pills in Kuwait
Abortion Pills Available In Dubai Abortion Pills Available In UAE Abortion
Pills Available In Abu Dhabi Abortion Pills Available In Sharjah Abortion
Pills Available In Fujairah Abortion Pills Available In Alain Abortion
Pills Available In Qatar Cytotec Available In Dubai Cytotec in Dubai Cyotec
Pills Dubai Abortion Cytotec Pills In Dubai whatsapp us at ?? +97158 994
3206 ?Buy abortion pills in Dubai, Buy abortion pills in Abudhabi, Buy
abortion pills in Sharja, Buy abortion pills in Abu az Zuluf, Buy abortion
pills in Ras Al Khaimah (RAK), Buy abortion pills in Ajman, Buy abortion
pills in Al Ain, abortion pills in DOHA, abortion pills in Abu Thaylah,
abortion pills in kuwait city, abortion pills in muscat, abortion pills in
jeddah,abortion pills in qatar,abortion pills in hawally,abortion pills in
salmiyah,abortion pills in al wakrah,abortion pills in riyadh,abortion
pills in manama,abortion pills in isa town,abortion pills in hamad town,
Buy abortion pills in Umm Al Quwain (UAQ), Buy abortion pills in Kuwait,
Abortion Pills Available In Dubai, Abortion Pills Available In UAE,
Abortion Pills Available In Abu Dhabi, Abortion Pills Available In Sharjah,
Abortion Pills Available In Fujairah, Abortion Pills Available In Alain,
Abortion Pills Available In Qatar, Cytotec Available In Dubai, Cytotec in
Dubai, Cytotec Pills Dubai, Abortion Cytotec Pills In Dubai UAE
we are providing cytotec 200mg abortion pill in Dubai, UAE. Medication
abortion offers an alternative to Surgical Abortion for women in the early
weeks of pregnancy.
We only offer abortion pills from 1 week-6 Months.
We then advise you to use surgery if its beyond 6 months.
Our Abu Dhabi, Ajman, Al Ain, Dubai, Fujairah, Ras Al Khaimah (RAK),
Sharjah, Umm Al Quwain (UAQ) United Arab Emirates Abortion Clinic provides
the safest and most advanced techniques for providing non-surgical, medical
and surgical abortion methods for early through late second trimester,
including the Abortion By Pill Procedure (RU 486, Mifeprex, Mifepristone,
early options French Abortion Pill), Tamoxifen, Methotrexate and Cytotec
(Misoprostol).
The Abu Dhabi, United Arab Emirates Abortion Clinic performs Same Day
Abortion Procedure using medications that are taken on the first day of the
office visit and will cause the abortion to occur generally within 4 to 6
hours (as early as 30 minutes) for patients who are 3 to 12 weeks pregnant.
When Mifepristone and Misoprostol are used, 50% of patients complete in 4
to 6 hours; 75% to 80% in 12 hours; and 90% in 24 hours. We use a regimen
that allows for completion without the need for surgery 99% of the time.
All advanced second trimester and late term pregnancies at our Tampa clinic
(17 to 24 weeks or greater) can be completed within 24 hours or less 99% of
the time without the need surgery. The procedure is completed with minimal
to no complications.
Our Women's Health Center located in Abu Dhabi, United Arab Emirates, uses
the latest medications for medical abortions (RU486, Mifeprex, Mifegyne,
Mifepristone, early options French abortion pill), Methotrexate and Cytotec
(Misoprostol).
The safety standards of our Abu Dhabi, United Arab Emirates Abortion
Doctors remain unparalleled. They consistently maintain the lowest
complication rates throughout the nation.
Our Physicians and staff are always available to answer questions and care
for women in one of the most difficult times in their lives.
The decision to have an abortion at the Abortion Clinic in Abu Dhabi,
United Arab Emirates, involves moral, ethical, religious, family,
financial, health and age considerations.
Buy abortion pills in Dubai,
Buy abortion pills in Oman,
Buy abortion pills in Abu Dhabi,
Buy abortion pills in Sharjah Fujairah,
Buy abortion pills in Ras Al Khaimah (RAK),
Buy abortion pills in Ajman,
Buy abortion pills in Al Ain,
Buy abortion pills in Umm Al Quwain (UAQ),
Buy abortion pills in Kuwait,
Abortion Pills Available In Dubai,
Abortion Pills Available In UAE,
Abortion Pills Available In Abu Dhabi,
Abortion Pills Available In Sharjah,
Abortion Pills Available In Fujairah,
Abortion Pills Available In Alain,
Abortion Pills Available In Qatar,
Cytotec Available In Dubai
Cytotec in Dubai,
abortion pills in Dubai for sale. +97158 994 3206
Cytotec Pills Dubai,
Abortion Cytotec Pills In Dubai UAE,
PRICE OF MIFE-KIT IN UAE
HOW TO GET ABORTION PILLS IN DUBAI
Safe Abortion in the UAE
MIFEPRISTONE IN UAE
MIFEPRISTONE IN DUBAI
LEVONORGESTRAL IN UAE
RU 486 IN DUBAI
RU 486 IN ABU DHABI
RU 486 IN UAE
ABORTION PILLS ONLINE DELIVERY IN DUBAI
ABORTION PILLS ON AMAZON IN UAE
SURGICAL ABORTION IN DUBAI
SURGICAL ABORTION IN ABU DHABI
Surgical Abortion in the UAE
COST OF SURGICAL ABORTION IN DUBAI/UAE
HOW MUCH IS SURGICAL ABORTION IN DUBAI
D & C IN DUBAI
COST OF D&C IN DUBAI/UAE/ABU DHABI
PRICE OF D & C PROCEDURE IN UAE
DILATION & CURETTAGE IN DUBAI/UAE
COST OF D & C IN DUBAI PRIVATE HOSPITAL
Whatsapp +97158 994 3206
Question Tags: +97158 994 3206 “Legit & Safe ABORTION PILLS, ABU DHABI
Sharjah Alain RAK city Satwa Jumeirah Al barsha, CYTOTEC, MIFEGEST KIT IN
DUBAI, Misoprostol, UAE” Contact me now via whatsapp…………. +97158 994 3206