Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

21 participants
3585 discussions

Re: [PATCH] drm/vmwgfx: Fix GEM_CLOSE returning -EINVAL for PRIME-imported surfaces

by kernel test robot

Hi Claire, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v7.3-rc3 next-20260916] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Claire-DuSoleil/drm-vmwgfx-F… base: https://gitlab.freedesktop.org/drm/misc/kernel.git drm-misc-next patch link: https://lore.kernel.org/r/20260917181312.12473-1-claire.m.dusoleil%40gmail.… patch subject: [PATCH] drm/vmwgfx: Fix GEM_CLOSE returning -EINVAL for PRIME-imported surfaces config: x86_64-buildonly-randconfig-1001-20260918 (https://download.01.org/0day-ci/archive/20260918/202609182113.RjRMgrW6-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260918/202609182113.RjRMgrW6-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202609182113.RjRMgrW6-lkp@intel.com/ All warnings (new ones prefixed by >>): >> Warning: drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:263 function parameter 'file_priv' not described in 'vmw_user_resource_lookup_handle' >> Warning: drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:263 function parameter 'file_priv' not described in 'vmw_user_resource_lookup_handle' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

4 days, 18 hours

Re: [PATCH v5 5/5] accel/amdxdna: do not fail a sync for a BO with no debug context

by Lizhi Hou

On 8/19/26 15:44, Taimuraz Kaitmazov wrote: > amdxdna_drm_sync_bo_ioctl() calls amdxdna_hwctx_sync_debug_bo() for every > FROM_DEVICE sync, which answers -EINVAL when the BO's assigned_hwctx names > no context. Only a BO attached with ATTACH_DEBUG_BO is ever given one, so > an ordinary read-back sync reports failure after its flush has already run. > > Ask for the debug sync only when the BO has a context. An unattached BO > carries AMDXDNA_INVALID_CTX_HANDLE and hwctx ids are allocated above it, so > the test is exact, -EINVAL keeps meaning that the named context is gone, > and the handle is not resolved twice. The field is written under dev_lock > and read here without it; the context is still resolved under that lock, so > a racing attach only decides whether this sync sees the buffer. > > Suggested-by: Lizhi Hou <lizhi.hou(a)amd.com> > Signed-off-by: Taimuraz Kaitmazov <taimuraz(a)kaitmazov.com> > --- > drivers/accel/amdxdna/amdxdna_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c > index 4be5298d1062..2613c94dd842 100644 > --- a/drivers/accel/amdxdna/amdxdna_gem.c > +++ b/drivers/accel/amdxdna/amdxdna_gem.c > @@ -1319,7 +1319,8 @@ int amdxdna_drm_sync_bo_ioctl(struct drm_device *dev, > XDNA_DBG(xdna, "Sync bo %d offset 0x%llx, size 0x%llx\n", > args->handle, args->offset, args->size); > > - if (args->direction == SYNC_DIRECT_FROM_DEVICE) > + if (abo->assigned_hwctx != AMDXDNA_INVALID_CTX_HANDLE && > + args->direction == SYNC_DIRECT_FROM_DEVICE) > ret = amdxdna_hwctx_sync_debug_bo(client, args->handle); Reviewed-by: Lizhi Hou <lizhi.hou(a)amd.com> > > put_obj:

5 days, 9 hours

Re: [PATCH v5 3/5] accel/amdxdna: do not warn when a sync request is rejected

by Lizhi Hou

On 8/19/26 15:44, Taimuraz Kaitmazov wrote: > amdxdna_drm_sync_bo_ioctl() answers a failed amdxdna_flush_bo() with > drm_WARN(). Both of that function's error returns are decided by the > ioctl's arguments, so SYNC_BO with an offset past the end of the BO > splats and taints the kernel from an unprivileged caller. > > Log it at debug level, since the same caller can repeat it. > > Signed-off-by: Taimuraz Kaitmazov <taimuraz(a)kaitmazov.com> > --- > drivers/accel/amdxdna/amdxdna_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c > index 77a9493cd7ba..0e0f844526ca 100644 > --- a/drivers/accel/amdxdna/amdxdna_gem.c > +++ b/drivers/accel/amdxdna/amdxdna_gem.c > @@ -1310,7 +1310,7 @@ int amdxdna_drm_sync_bo_ioctl(struct drm_device *dev, > amdxdna_gem_unpin(abo); > > if (ret) { > - drm_WARN(&xdna->ddev, 1, "Can not get flush memory"); > + XDNA_DBG(xdna, "Flush BO %d failed, ret %d", args->handle, ret); Reviewed-by: Lizhi Hou <lizhi.hou(a)amd.com> > goto put_obj; > } > }

5 days, 9 hours

[PATCH v3 0/2] drm/drm_crtc: dma_fence_ops fixes

by André Draszik

Hi, These patches fix two issues in the drm/drm_crtc driver. Initially I was hitting the BUG_ON() in a scenario as explained in the commit message of what is now the second patch in this series. After posting, sashiko.dev noticed another issue, that was previously masked by the now-removed BUG_ON(). Since we can't have a loud BUG() be replaced with silent data corruption or worse, I've also added a patch to address this issue highlighted by sashiko.dev. I believe its observation and analysis to be correct. Cheers, Andre' Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v3: - Philipp: - patch 1: update kerneldoc, add Fixes: - patch 2: shorten commit message - explicitly Cc: stable - collect tag - Link to v2: https://lore.kernel.org/r/20260708-linux-drm_crtc_fix2-v2-0-cf72be75d75a@li… Changes in v2: - add new patch 1 to address sashiko observation - original patch 1 becomes patch 2 - patch 2: - don't turn fence_to_crtc() into macro (Jani, Philipp) - update commit message to include reference to deprecated use of BUG - Link to v1: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@li… --- André Draszik (2): drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name() drivers/gpu/drm/drm_crtc.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) --- base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

1 week

Re: [PATCH] dma-fence: Fix dma_fence_enable_signaling() reference in kernel-doc

by Christian König

On 9/12/26 00:11, Karl Mehltretter wrote: > The kernel-doc comment of dma_fence_is_signaled_locked() refers to > dma_fence_enable_sw_signaling, which was renamed to > dma_fence_enable_signaling by commit 9370a5c664e8 ("dma-buf: rename > dma_fence_enable_sw_signaling"). Say dma_fence_enable_signaling. > > Fixes: 9370a5c664e8 ("dma-buf: rename dma_fence_enable_sw_signaling") > Assisted-by: LLM > Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com> I'm really wondering why that was not automatically renamed. Anyway reviewed and pushed to drm-misc-next. Thanks, Christian. > --- > include/linux/dma-fence.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index 158cd609f1036e56668867f092041213cbf30427..3aa85be43aada5a80ea2e1cecc5f76824b434d14 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -501,7 +501,7 @@ dma_fence_test_signaled_flag(struct dma_fence *fence) > * Returns true if the fence was already signaled, false if not. Since this > * function doesn't enable signaling, it is not guaranteed to ever return > * true if dma_fence_add_callback(), dma_fence_wait() or > - * dma_fence_enable_sw_signaling() haven't been called before. > + * dma_fence_enable_signaling() haven't been called before. > * > * This function requires &dma_fence.lock to be held. > *

1 week, 1 day

[PATCH v5 00/18] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the client chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, expose the provider to dma-buf importers, and let mlx5 ask rather than assume. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (18): PCI/P2PDMA: Document pdev->p2pdma lifetime rules PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing dma-buf: Let importers ask how peer-to-peer traffic is routed RDMA/mlx5: Ask P2PDMA whether ATS takes a direct peer-to-peer route Documentation/admin-guide/kernel-parameters.txt | 9 +- Documentation/driver-api/pci/p2pdma.rst | 69 +++ drivers/dma-buf/dma-buf-mapping.c | 41 +- drivers/dma-buf/dma-buf.c | 1 + drivers/infiniband/core/uverbs.h | 1 - drivers/infiniband/core/uverbs_std_types_dmabuf.c | 7 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 36 +- drivers/infiniband/hw/mlx5/mr.c | 40 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 637 +++++++++++++++++++--- drivers/pci/pci.c | 7 +- drivers/pci/pci.h | 26 + drivers/pci/pci_acs_test.c | 609 +++++++++++++++++++++ drivers/pci/quirks.c | 6 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 8 +- include/linux/dma-buf-mapping.h | 4 +- include/linux/dma-buf.h | 5 + include/linux/pci-p2pdma.h | 57 +- 19 files changed, 1440 insertions(+), 139 deletions(-) --- base-commit: 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72 change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 prerequisite-message-id: <20260830-batch-p2p-fixes-v1-0-5044e8dfbe2e(a)nvidia.com> prerequisite-patch-id: 6b25c7fcf164cdfc14e9fac5b908d97fcf6509d7 prerequisite-patch-id: 0d083c281001365aae4b35544cf28891a6ab9a96 prerequisite-patch-id: bfd9dabf271f3cc9a3a61f46387d20c20311363d prerequisite-patch-id: fad0275efc722830fc591509506c0a5e4f581073 prerequisite-patch-id: 0c83bee688fec1f6d1564654df7c630fa6a4a978 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 week, 4 days

Re: [PATCH] dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels

by Christian König

On 9/7/26 04:00, Karl Mehltretter wrote: > Commit 646013f513f3 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG > kernels") changed the default of DMABUF_DEBUG to "y if DEBUG", but no > Kconfig symbol DEBUG exists, so the option has had no default since. > > Use DEBUG_KERNEL, the Kconfig symbol for a debug kernel. > > Fixes: 646013f513f3 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG kernels") > Assisted-by: LLM > Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com> Reviewed and pushed to drm-misc-fixes. Thanks, Christian. > --- > This enables the dma-buf debug checks on every CONFIG_DEBUG_KERNEL > configuration, which is what 646013f513f3 set out to do. If that is too > broad today, the alternative is to restore the previous > "default y if DMA_API_DEBUG". > > drivers/dma-buf/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > index 7efc0f0d0712..e4f078a326a4 100644 > --- a/drivers/dma-buf/Kconfig > +++ b/drivers/dma-buf/Kconfig > @@ -43,7 +43,7 @@ config UDMABUF > config DMABUF_DEBUG > bool "DMA-BUF debug checks" > depends on DMA_SHARED_BUFFER > - default y if DEBUG > + default y if DEBUG_KERNEL > help > This option enables additional checks for DMA-BUF importers and > exporters. Specifically it validates that importers do not peek at the > > base-commit: 986c24e0fe44f844b44d365b71ce831947f50298 > -- > 2.53.0 >

1 week, 4 days

Re: [PATCH v2 00/15] accel/qda: Qualcomm DSP Accelerator driver

by Bjorn Andersson

On Wed, Sep 09, 2026 at 02:48:17PM +0300, Dmitry Baryshkov wrote: > On Tue, Sep 08, 2026 at 05:44:10PM -0500, Bjorn Andersson wrote: > > On Wed, Aug 26, 2026 at 06:37:00PM +0530, Ekansh Gupta wrote: > > > On 20-08-2026 20:17, Rob Clark wrote: > > > > On Wed, Aug 19, 2026 at 11:15 PM Krzysztof Kozlowski <krzk(a)kernel.org> wrote: > > > >> > > > >> On 19/08/2026 17:48, Rob Clark wrote: > > > >>> On Wed, Aug 19, 2026 at 8:27 AM Krzysztof Kozlowski <krzk(a)kernel.org> wrote: > > > >>>> The rule of usptream development is that we do not accept duplicated > > > >>>> code, just because a vendor wants to write something new. This is > > > >>>> basically the concept applied all over the drivers tree, where we pushed > > > >>>> back against all sorts of duplications all over the vendors. > > > >>>> > > > >>>> What I miss in this thread is why would there be any exception here. We > > > >>>> do not grant exceptions from standard practices on "I want" reasons. > > > >>> > > > >>> I agree that we should not have duplicated drivers just for vendor > > > >>> lolz. But when it comes to adopting common frameworks and integrating > > > >>> better into the ecosystem, this doesn't seem like something we should > > > >>> actively discourage. I don't think this is a case of vendor lolz, but > > > >> > > > >> No one discourages it. Following standard Linux kernel practices and > > > >> requirements is not discouraging, do not twist the narrative here. > > > >> Again, it is standard upstream review telling that we do not duplicate > > > >> drivers. Ever, unless there is serious exception needed. > > > > > > > > I wasn't trying to twist the narrative, just trying to come up with a > > > > path forward that isn't "no" or "improve existing driver", since > > > > neither of those gets us towards a future using common frameworks. > > > > > > > >> I asked why there should be an exception granted? Is the reason for > > > >> exception following: > > > >> "We want to adopt common framework" > > > >> ? > > > > > > > > Possibly? But I don't think we want two drivers to be any sort of > > > > long term solution. (Ie. as long as venus/iris have co-exist.) > > > > > > > >> > > > >>> rather reacting to drm/accel emerging as the standard framework for > > > >>> this sort of driver. > > > >>> > > > >>> So how do we get from here to there? > > > >> > > > >> What is wrong with my proposal? > > > > > > > > Maybe I missed something, my understanding was your proposal was > > > > "Grow/replace/improve existing driver instead of coming with a > > > > duplicate".. grow or improve doesn't move us toward common > > > > frameworks. Maybe "replace" is a valid option. If there is something > > > > I missed, then I apologize. > > > > > > > > Options I can think of are: > > > > > > > > 1. Hardware cutoff.. new hw gets new driver, existing hw gets existing > > > > driver > > > > 2. Backwards compat chardev registered by new driver, providing existing > > > > UABI. I'm not 100% sure about the feasibility/drawbacks of this.. > > > > AFAIU the fastrpc folks where planning a backwards compat layer in > > > > userspace, so maybe it is possible. > > > > 3. exception? > > > > > > > > I'd like to know what the feasibility of #2 is, since at a high level > > > > that sounds like the best option. Possibly limit exposure of legacy > > > > UABI to existing hw so we don't get into a place of needing to extend > > > > the legacy UABI for new hw? > > > > > > > > But #1 sounds like a non-controversial place to start regardless. > > > > Possibly with #2 coming as followup and necessary step before eventual > > > > migration to new driver for existing hw? > > > > > > > > Even if we start with #2, how do we handle first-merge-window > > > > bugs/regressions without reverting addition of new driver and removal > > > > of old? It seems like we'd need a window of a couple release cycles > > > > where both drivers exist? > > > > > > > > Maybe others have other/better options in mind? > > > To all, I'm seeking on the approach I should follow to go ahead here. I > > > can work on implementing #1(as per Rob's list) with hw specific > > > compatible for v4 if it's acceptable. > > > > > > > I don't see any reason for you to define a "hw specific compatible", > > because as you have shown in this series (and as Rob point out), there's > > no difference in the "hardware". > > > > The only reason for your "hw specific compatible" is to make a software > > selection in Linux - and that's not what DeviceTree is for. > > That's not exactly true. There are protocol differences. For example, > polling mode is supported only since a certain timeline in the history. > Likewise other interface features are not supported on all the FastRPC > devices. For the polling mode support we were already beaten by the lack > of SoC-specific compats. > I can see the benefit of capturing some of the generational features in a compatible, like the changes related to address width. But for pure software features that doesn't have an actual bearing in the hardware, I'd prefer if we relied on dynamic discovery. But none of that applies to the question of "can I use compatible to select if we should use the new or old Linux driver". > > As such, I don't see that you have a DeviceTree problem at all, because > > this is a Linux-internal problem. > > > > > #2(compat driver) is something that we are still exploring as we > > > couldn't find any standard way to achieve it. We might start a separate > > > discussion for that once we have few possible designs with us. > > > > > > > This is the actual problem! > > > > We have existing user space that depends on the ioctl interface exposed > > by the current misc driver. You must not break these. > > This is clear. > > > Hardware cutoff is not a viable solution, because that's just a > > declaration that we'll let the old platforms rotten - or alternatively > > you commit to maintain two drivers to the very same feature and quality > > level. > > > > So the only reasonable solution is #2; from there it's a valid question > > if you reach that point my stepwise migrating the current misc driver > > that solution, or if you present a new driver with the fully backwards > > compatible interface, alongside the new ABI. > > I think the general direction was #3 (or #2.1): implement a shim layer > on top of the QDA driver as a separate module. Put all the historical > over-complicated solutions into that shim module and let it die at some > point. Current fastrpc driver lets userspace specify buffers in several > different ways, forcing the kernel driver to perform a lot of work > with buffer addresses. I don't think that this legacy code should be a > part of the QDA. It can go to qda-fastrpc-shim, keeping it out of the > kernel memory if it's not necessary. > > > But this does bring to a question which the cover letter should explain > > - but doesn't: what problem does this patch series actually solve? > > I agree that it should be a part of the cover letter. > > As a person who triggered this work, I can propose my reasons: > > - Current driver has over-complicated memory manager (both on the > userspace and on the kernel side). The userspace library is spaghetti, but when I wrote my own it turned out quite succinct. The ioctl structs certainly could have been cleaner, and documented, but it seems to me that a fair amount of the complexity comes from the different use cases - such as SMMU vs XPU, secure and unsecure buffers, remnants of now unsupported options. I'm presuming that QDA will need to adopt most of these, and that QDA support will be bolted into the spaghetti library. > Correspondng uAPI is not really > suitable for virtualization. Using GEM simplifies both the kernel > driver and uAPI. Also using handle-offset-length to specify the > buffers makes it easy to support virtual QDA devices. I'm looking forward to learn more about this! > > - Current driver predates the accel subsystem. Using common subsystem > simplifies reviews. The QDA driver has gotten several comments about > the usage of the DMA-BUFs. It'not unlikely that the same issues are > present in the current FastRPC driver, just being unnoticed. Yeah, this is unfortunate. It would certainly be nice to have a documented and clean ABI. > > - The ideas present in the current FastRPC driver also predate the > current design practices. The uAPI was created in the ad-hoc way, just > following the momentary needs. Driver code also shows the result of > that, having enough of the spaghetti code. > Yeah, again, this isn't desirable. > Given all of that, yes, it is possible to provide an evolution of the > FastRPC driver into the accel+shim, improve the code quality meanwhile > and end up with the good enough split. However I think that the path > taken would be longer and the net result might be worse. > > With all of that in mind, my suggestion is to continue working on the > QDA driver, get the core of it to integrate nicely with the accel and > DMA-BUF usage requirements and implement the (minimal?) fastrpc shim on > top of it. > If you believe this is the way to reach the proper design, then I won't object. My requirement is that my userspace continues to work when my distro suddenly switches FASTRPC=n/QDA=m. I have no problems with dropping the fastrpc driver once the QDA is drop-in-compatible. I'm also open to marking the compat layer deprecated and eventually drop it once we're certain that users have moved to a userspace that used the accel interface. But we can't merge the QDA driver as long as we believe that implementing a compat layer will be hard/impossible. Regards, Bjorn > > -- > With best wishes > Dmitry

1 week, 5 days

Re: [RFC PATCH] misc: fgds: enable GPU-NVMe direct I/O via POSIX and io_uring

by Christian König

On 9/10/26 05:57, Li Wang wrote: ... >> AMD came up with something similar, but all those approaches are so fundamentally broken that we didn't even considered upstreaming it. >>> And you are using this as a "bypass" for the normal accel subsystem, >>> shouldn't this be part of that subsystem instead of a custom user/kernel >>> api like you are creating here? >> >> As far as I know there is a patch set under review and even already partially merged which enables exactly that functionality as general feature for DMA-buf which is vendor independent and should at least in theory work with all drivers. >> >> I'm really surprised that somebody is still working on the vendor specific stuff. > As you pointed out, every vendor has been inventing their own way and interfaces to support GDS, > introducing custom kernel modules and proprietary UAPI interfaces, with varying performance that > leaves developers heavily frustrated. Apologies for not making this clear enough in our commit > messages, which understandably caused some confusion. We merely borrowed the name "GDS" to describe > the functional purpose of fgds. > > In fact, we believe fgds offers four key advantages: > (1) GPU platform independence; > (2) POSIX/io_uring interface compatibility; > (3) Higher performance than GDS; > (4) Minimal kernel footprint and UAPI footprint > > Regarding (1), (2), and (3), please allow me to briefly explain the design mechanism of fgds: > fgds turns a GPU memory buffer into a POSIX/io_uring-compatible user-space virtual address via > three main steps: > > Step 1: Utilizing ZONE_DEVICE support, we remap the GPU memory exposed via PCIe BAR into struct pages > using devm_memremap_pages(); > > Step 2: Utilizing dma-buf support, the GPU memory buffer is exported as a dma-buf file descriptor (fd). > Using this fd as a bridge, we look up the corresponding DMA addresses for the GPU memory buffer inside > the kernel; > > Step 3: Through mmap, we insert the struct pages corresponding to the GPU memory buffer into the userspace > VMA, mapping their physical/DMA addresses directly. The virtual address returned by mmap can then be directly > passed into standard POSIX or io_uring interfaces. Well long story short what you do here is completely broken. Approaches like those have been suggested before and we added both documentation as well as code to prevent such hacks from working. Please see Pavel Begunkov patch set on the LKML which adds DMA-buf support to io_uring for how to do it correctly. Just google for "Add dmabuf read/write via io_uring". Regards, Christian.

1 week, 5 days

Re: [PATCH v6 04/12] arm64/mm: Export set_direct_map_*_noflush() APIs

by Christoph Hellwig

On Fri, Sep 04, 2026 at 12:44:55PM +0200, Thierry Reding wrote: > From: Thierry Reding <treding(a)nvidia.com> > > Drivers that use this may want to be built as a module, so export them. That's one of the worst commit log ever. No, we don't just export core symbols dealing with the kernel direct map because "Drivers that use this may want to be built as a module". For one exporting this at all needs a very good justification and not just hand waiving. But more importantly if we can't avoid exporting it, it needs to be exported at the tightest sensible scope. E.g. for a given module if it is so special, or a namespace if it's not that special. But in doubt we should have a proper core abstraction instead of opening up direct map manipulation to random modules.

1 week, 6 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig