On Wed, Jul 29, 2026 at 12:45:47PM +0100, Pavel Begunkov wrote:
> It was exposed in early version as I was passing a [{dma,len}, ...]
> array, but we moved from that. Maybe I should put the minimum
> segment size in the map structure, and (possibly over) split using
> that for now? Keith had this chunk in his patches:
>
> + int offset = offset_in_page(bio->bi_iter.bi_bvec_done);
> +
> + nsegs = ALIGN(bio->bi_iter.bi_size + offset, PAGE_SIZE) >>
> + PAGE_SHIFT;
> + if (bio->bi_iter.bi_size > max_bytes) {
> + bytes = max_bytes;
> + nsegs = (bytes + offset) >> PAGE_SHIFT;
> + } else if (nsegs > lim->max_segments) {
> + nsegs = lim->max_segments;
> + bytes = PAGE_SIZE * nsegs - offset;
> + } else {
> + *segs = nsegs;
> + return NULL;
> + }
This seems very pessimistic, especially for the case of the registration
only having a single segment, which I'd expect to be fairly common due
to P2P bar mappings, huge pages or IOMMU coalescing. So at very least
we'd want to special case that, but in an idea world the caller would
be required to provide a useful nr_segments for the I/O.
On Wed, Jul 29, 2026 at 03:47:23PM +0530, Anuj Gupta/Anuj Gupta wrote:
> > But I also don't understand what the use case for this function
> > is to start with. struct sg_table tells us how many segments
> > exist on the DMA side in the nents member, which should be just
> > fine for the SGL threshold calculation.
>
> sg_table->nents covers the entire exported buffer (<=1GiB), while a
> request only covers a subrange[bi_offset, bi_offset+payload). Using
> nents would overcount the request's segments.
Urgg, yes.
> >> + if (!entries)
> >> + return BLK_STS_IOERR;
> >> + if (entries > NVME_MAX_SEGS)
> >> + return BLK_STS_AGAIN;
> >
> > Given that the block layer enforced data in rw/command and the
> > max_segments limit, why do we need the extra check here?
>
> A dmabuf bio reports nsegs=1 (bio_split_io_at) to the block layer, so
> max_segments isn't enforced against the SG entries actually spanned by
> the request. Hence the explicit check.
We'll need to expose the actual nsegs to the block layer and split
based on that. Otherwise I/O might work or fail based on the device
capabilities.
On Wed, Jul 29, 2026 at 11:37:19AM +0100, Pavel Begunkov wrote:
> On 7/29/26 07:59, Christoph Hellwig wrote:
>> The method name feels a bit convoluted, but given all the
>> previous discussions I don't care too strongly. I'll leave
>> the dma-buf side review to those who understand it.
>
> I assume you mean this:
Yes.
>
> + int (*init_dma_buf_io_ctx)(struct file *, struct dma_buf_io_ctx *);
>
> I agree, and all dma_buf_io_[ctx,map] look clunky, but I don't
> see what I can drop out of the name. Suggestions? Maybe I at least
> should make the fs op sth like "register_dma_buf".
I just remember scares from the last discussion :)
register_dma_buf sounds fine to be, but unless I misremember there
were objections to that before.
>
> --
> Pavel Begunkov
---end quoted text---
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)
Hello everyone,
I wanted to share a website that I've been using recently whenever I have a few minutes to spare: Free Top Games. Web site: https://freetopgames.io/
What I like most is that everything runs directly in the browser, so there's nothing to install or update. The site includes a good mix of game genres such as puzzle, racing, shooting, sports, adventure, and casual games, making it easy to find something that fits your mood.
A few things I appreciate:
Fast loading games with no downloads required.
Works on desktop, tablet, and mobile browsers.
A wide variety of free titles that are updated regularly.
Great for short gaming sessions during breaks.
I'm always interested in discovering browser-based gaming sites with clean interfaces and interesting game collections. If anyone here has other recommendations for free web game platforms, I'd love to hear them.
Thanks for reading!
Some games are enjoyable because they are relaxing, while others are memorable because they constantly surprise you. Level Devil belongs to the second category. It is a compact platform game built around traps, unexpected changes, and trial-and-error learning. Each stage may look simple at first, but the level itself can shift in ways that challenge your expectations.
The fun comes from discovering what each room is hiding and gradually improving through observation and practice.
https://leveldevilfull.com
Gameplay
The main goal is straightforward: guide your character through the stage and reach the exit. You usually move left and right, jump over obstacles, and avoid hazards such as spikes, pits, or moving platforms. However, the game’s real challenge is that familiar rules may suddenly change.
A platform might disappear, the screen could shift, or an apparently safe path may reveal a trap. These surprises are designed to make players react quickly, but rushing often leads to mistakes. Instead, each failed attempt provides useful information about the level.
The controls are generally easy to understand, which makes the game accessible to beginners. The difficulty comes from timing, patience, and learning how the stage behaves. This makes every successful jump feel satisfying, especially after several attempts.
Tips for Playing
First, take your time when entering a new area. Look for unusual gaps, suspicious platforms, and objects that seem deliberately placed. The level may be testing whether you notice a visual clue.
Second, treat failure as part of the experience. Losing does not necessarily mean you played badly; it often reveals something important about the stage. Remember what happened and adjust your next attempt.
It also helps to use short, controlled movements. Holding a direction for too long can send your character into a hazard, while careful taps give you more control. When jumping, focus on both the takeoff and the landing. Some platforms require you to prepare for the next move immediately.
Finally, avoid becoming frustrated. Take a short break if a section feels repetitive, then return with a fresh mind. Many difficult moments become easier once you stop trying to force them.
Conclusion
Level Devil is a good example of how simple controls can support creative and challenging gameplay. Its surprises, quick restarts, and unusual level design make it enjoyable for players who like experimentation. Whether you play for a few minutes or try to complete every stage, the best approach is to stay curious, observe carefully, and learn from each attempt.
On Tue, Jul 28, 2026 at 10:29:21PM +0100, Pavel Begunkov wrote:
> From: Anuj Gupta <anuj20.g(a)samsung.com>
>
> Add SGL support in addition to PRP for dmabuf-backed requests,
> coalescing the mapping's sg_table into NVMe SGL data descriptors.
>
> Signed-off-by: Anuj Gupta <anuj20.g(a)samsung.com>
> [pavel: rebased]
> Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com>
> ---
> drivers/nvme/host/pci.c | 191 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 187 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index f1b67c191892..cbb321fb7c50 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1287,12 +1287,18 @@ static blk_status_t nvme_pci_setup_data_prp(struct request *req,
> return BLK_STS_IOERR;
> }
>
> +static void nvme_pci_sgl_set_data_addr(struct nvme_sgl_desc *sge,
> + dma_addr_t addr, u32 len)
> +{
> + sge->addr = cpu_to_le64(addr);
> + sge->length = cpu_to_le32(len);
> + sge->type = NVME_SGL_FMT_DATA_DESC << 4;
> +}
> +
> static void nvme_pci_sgl_set_data(struct nvme_sgl_desc *sge,
> struct blk_dma_iter *iter)
> {
> - sge->addr = cpu_to_le64(iter->addr);
> - sge->length = cpu_to_le32(iter->len);
> - sge->type = NVME_SGL_FMT_DATA_DESC << 4;
> + nvme_pci_sgl_set_data_addr(sge, iter->addr, iter->len);
> }
The naming is a bit confusing (and me passing the iter to
nvme_pci_sgl_set_data is probably at faul for that). So maybe
spin out a prep patch to rename the old nvme_pci_sgl_set_data
to nvme_pci_dma_iter_set_sgl or so, and then add the new one
as nvme_pci_sgl_set_data (as before the dma_iter conversion).
>
> +static unsigned int nvme_pci_dmabuf_sgl_nents(struct request *req,
> + dma_addr_t *first_dma,
> + u32 *first_len)
This is a really good example why the aligning to the opening braces
produces totally unreadble code..
But I also don't understand what the use case for this function
is to start with. struct sg_table tells us how many segments
exist on the DMA side in the nents member, which should be just
fine for the SGL threshold calculation.
> +{
> + struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> + struct bio *bio = req->bio;
> + struct nvme_dmabuf_map *map = to_nvme_dmabuf_map(bio->bi_dmabuf_map);
> + size_t length = blk_rq_payload_bytes(req);
> + struct nvme_sgl_desc *sg_list = NULL;
> + dma_addr_t sgl_dma = 0, last_end = 0;
> + unsigned int mapped = 0;
> + unsigned long tmp;
> + struct scatterlist *sg;
> + size_t offset, remaining;
> + bool have = false;
> +
> + if (!entries)
> + return BLK_STS_IOERR;
> + if (entries > NVME_MAX_SEGS)
> + return BLK_STS_AGAIN;
Given that the block layer enforced data in rw/command and the
max_segments limit, why do we need the extra check here?
> + continue;
> + }
> +
> + addr += offset;
> + sg_len -= offset;
> + offset = 0;
> +
> + while (sg_len && remaining) {
These can't be false on the first iteration, so maybe turn this into
a do {} while loop?
> + u32 chunk = min_t(size_t, remaining, sg_len);
> +
> + if (have && last_end == addr) {
> + u32 old = le32_to_cpu(sg_list[mapped - 1].length);
> +
> + sg_list[mapped - 1].length = cpu_to_le32(old + chunk);
Overly long line.
> + } else {
> + if (WARN_ON_ONCE(mapped == entries))
> + goto err_free;
> + nvme_pci_sgl_set_data_addr(&sg_list[mapped++],
> + addr, chunk);
> + }
Why do we need this merging? dma_map_sg should have already done
any interesting merging, or am I missing something?
> + if (use_sgl != SGL_UNSUPPORTED) {
> + dma_addr_t first_dma;
> + u32 first_len;
> + unsigned int entries;
> +
> + entries = nvme_pci_dmabuf_sgl_nents(req, &first_dma,
> + &first_len);
> +
> + if (use_sgl == SGL_FORCED) {
> + ret = nvme_rq_setup_dmabuf_sgl(req, nvmeq,
> + entries, first_dma, first_len);
> + return ret == BLK_STS_AGAIN ? BLK_STS_IOERR : ret;
> + }
> +
> + if (sgl_threshold && entries &&
> + DIV_ROUND_UP(blk_rq_payload_bytes(req), entries) >=
> + sgl_threshold) {
> + ret = nvme_rq_setup_dmabuf_sgl(req, nvmeq,
> + entries, first_dma, first_len);
> + if (ret != BLK_STS_AGAIN)
> + return ret;
> + }
> + }
Various overly long lines. Please factor out a helper for the
decisions to use sgl vs not instead of open coding it here.
Basketball Stars is the perfect game for anyone who loves fast-paced street basketball action! From smooth dribble moves and ankle-breaking crossovers to clutch shots and powerful dunks, every match feels intense and competitive.
The game’s easy controls make it simple to start playing, but mastering the timing, defense, and shooting mechanics takes real skill. Whether you’re playing quick one-on-one matches or climbing the ranked leaderboard, Basketball Stars keeps every game exciting.
One of the best parts is the character customization. You can unlock new outfits, courts, basketballs, and upgrades to create your own unique style on the court. Playing against real opponents online also adds a fun challenge because every player has a different strategy.
If you enjoy basketball games with arcade-style gameplay and nonstop action, Basketball Stars is definitely worth checking out. Step onto the court and show everyone who the real MVP is!
WEB: https://basketballstars2026.io
> +static int nvme_init_dma_buf_io_ctx(struct block_device *bdev,
> + struct dma_buf_io_ctx *ctx)
Please stick to two-tab indents for function declaration continuation
for the nvme code to keep the code easy to maintain.
> +#if defined(CONFIG_DMA_SHARED_BUFFER)
This should be good old #ifdef. Same in a few other places over
the series.
Modulo these minor nits the patch looks good.