* Re: [PATCH 02/15] accel/qda: Add QDA driver documentation
From: Dmitry Baryshkov @ 2026-05-20 14:12 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-2-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:52AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Add documentation for the Qualcomm DSP Accelerator (QDA) driver under
> Documentation/accel/qda/. The documentation covers the driver
> architecture, GEM-based buffer management, IOMMU context bank
> isolation, and the RPMsg transport layer.
>
> The user-space API section describes the DRM IOCTLs for session
> management, GEM buffer allocation, and remote procedure invocation via
> the FastRPC protocol, along with a typical application lifecycle
> example. Sections for dynamic debug and basic testing are also
> included.
>
> Wire the new documentation into the Compute Accelerators index at
> Documentation/accel/index.rst.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> Documentation/accel/index.rst | 1 +
> Documentation/accel/qda/index.rst | 13 ++++
> Documentation/accel/qda/qda.rst | 146 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 160 insertions(+)
>
> diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst
> index cbc7d4c3876a..5901ea7f784c 100644
> --- a/Documentation/accel/index.rst
> +++ b/Documentation/accel/index.rst
> @@ -10,4 +10,5 @@ Compute Accelerators
> introduction
> amdxdna/index
> qaic/index
> + qda/index
> rocket/index
> diff --git a/Documentation/accel/qda/index.rst b/Documentation/accel/qda/index.rst
> new file mode 100644
> index 000000000000..013400cf9c25
> --- /dev/null
> +++ b/Documentation/accel/qda/index.rst
> @@ -0,0 +1,13 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +==================================
> +accel/qda Qualcomm DSP Accelerator
> +==================================
> +
> +The QDA driver provides a DRM accel based interface for Qualcomm DSP offload.
> +It uses the FastRPC protocol and integrates with DRM and GEM infrastructure
> +for device and buffer management.
> +
> +.. toctree::
> +
> + qda
> diff --git a/Documentation/accel/qda/qda.rst b/Documentation/accel/qda/qda.rst
> new file mode 100644
> index 000000000000..9f49af6e6acc
> --- /dev/null
> +++ b/Documentation/accel/qda/qda.rst
> @@ -0,0 +1,146 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +=====================================
> +Qualcomm DSP Accelerator (QDA) Driver
> +=====================================
> +
> +Introduction
> +============
> +
> +The QDA driver is a DRM accel driver for Qualcomm's DSPs. It provides a
> +DRM accel based interface for Qualcomm DSP offload, supporting workloads
> +such as AI inference, computer vision, audio processing, and sensor offload
> +on Qualcomm SoCs. It uses the FastRPC protocol and integrates with DRM and
> +GEM infrastructure for device and buffer management.
> +
> +Key Features
> +============
> +
> +* **DRM accel Interface**: Exposes a standard character device node
> + (e.g., ``/dev/accel/accel0``) via the DRM accel subsystem.
> +* **FastRPC Protocol**: Implements the FastRPC protocol for communication
> + between the application processor and the DSP.
> +* **GEM Buffer Management**: Uses the DRM GEM interface for buffer
> + allocation, lifecycle management, and DMA-BUF import/export.
> +* **IOMMU Isolation**: Uses IOMMU context banks to enforce memory isolation
> + between different DSP user sessions.
> +* **Modular Design**: Clean separation between the core DRM logic, the
> + memory manager, and the RPMsg-based transport layer.
> +
> +Architecture
> +============
> +
> +The QDA driver consists of several functional blocks:
> +
> +1. **Core Driver (``qda_drv``)**: Manages device registration, file operations,
> + and DRM accel integration.
> +2. **Memory Manager (``qda_memory_manager``)**: A flexible memory management
> + layer that handles IOMMU context banks. It supports pluggable backends
> + (such as DMA-coherent) to adapt to different SoC memory architectures.
> +3. **GEM Subsystem**: Implements the DRM GEM interface for buffer management:
> +
> + * **``qda_gem``**: Core GEM object management, including allocation, mmap
> + operations, and buffer lifecycle management.
> + * **``qda_prime``**: PRIME import functionality for DMA-BUF interoperability
> + with other kernel subsystems.
> +
> +4. **Transport Layer (``qda_rpmsg``)**: Abstraction over the RPMsg framework
> + to handle low-level message passing with the DSP firmware.
> +5. **Compute Bus (``qda_compute_bus``)**: A custom virtual bus used to
> + enumerate and manage the specific compute context banks defined in the
> + device tree. The bus was introduced because IOMMU context banks (CBs) are
> + synthetic constructs — not real platform devices — making a platform driver
> + an incorrect abstraction for them. The earlier platform-driver approach also
> + had a race condition: device nodes were created before the RPMsg channel
> + resources were fully initialized, and because ``probe`` runs asynchronously,
> + applications could open a CB device and attempt to start a session before
> + the underlying transport was ready. The compute bus makes CB lifetime
> + explicitly subordinate to the parent QDA device, closing that window.
> +6. **FastRPC Core (``qda_fastrpc``)**: Implements the protocol logic for
> + marshalling arguments and handling remote invocations.
> +
> +User-Space API
> +==============
> +
> +The driver exposes a set of DRM-compliant IOCTLs:
> +
> +* ``DRM_IOCTL_QDA_QUERY``: Query DSP type (e.g., "cdsp", "adsp")
> + and capabilities.
> +* ``DRM_IOCTL_QDA_REMOTE_SESSION_CREATE``: Initialize a new process context
> + on the DSP.
> +* ``DRM_IOCTL_QDA_REMOTE_INVOKE``: Submit a remote method invocation (the
> + primary execution unit).
> +* ``DRM_IOCTL_QDA_GEM_CREATE``: Allocate a GEM buffer object for DSP usage.
> +* ``DRM_IOCTL_QDA_GEM_MMAP_OFFSET``: Retrieve mmap offsets for memory mapping.
> +* ``DRM_IOCTL_QDA_REMOTE_MAP`` / ``DRM_IOCTL_QDA_REMOTE_MUNMAP``: Map or unmap
> + buffers into the DSP's virtual address space. Each accepts a ``request``
> + field selecting between a legacy operation (``QDA_MAP_REQUEST_LEGACY`` /
> + ``QDA_MUNMAP_REQUEST_LEGACY``) and an attribute-based operation
> + (``QDA_MAP_REQUEST_ATTR`` / ``QDA_MUNMAP_REQUEST_ATTR``).
Explain, what happens in the users don't map the buffers into the DSP
space. Will DRM_IOCTL_QDA_REMOTE_INVOKE handle the mapping or not? What
is the difference between those two modes?
Would the driver benefit from using GPUVM?
> +
> +Usage Example
> +=============
> +
> +A typical lifecycle for a user-space application:
> +
> +1. **Discovery**: Open ``/dev/accel/accel*`` and use
> + ``DRM_IOCTL_QDA_QUERY`` to identify the DSP domain served by that
> + device node.
> +2. **Initialization**: Call ``DRM_IOCTL_QDA_REMOTE_SESSION_CREATE`` to
> + establish a session and create a process context on the DSP.
> +3. **Memory**: Allocate buffers via ``DRM_IOCTL_QDA_GEM_CREATE`` or import
> + DMA-BUFs (PRIME fd) from other drivers using ``DRM_IOCTL_PRIME_FD_TO_HANDLE``.
> +4. **Execution**: Use ``DRM_IOCTL_QDA_REMOTE_INVOKE`` to pass arguments and
> + execute functions on the DSP.
> +5. **Cleanup**: Close file descriptors to automatically release resources and
> + detach the session.
I'd have expected the description of the actual example. I.e. clone the
app from https://the.addr, prepare clang >= NN.MM, QAIC (https://foo),
run make, run the app, check the results. I'd remind that DRM Accel has
a very specific requirement of having the working toolhain in the
open-source.
> +
> +Internal Implementation
> +=======================
> +
> +Memory Management
> +-----------------
> +The driver's memory manager creates virtual "IOMMU devices" that map to
> +hardware context banks. This allows the driver to manage multiple isolated
> +address spaces. The implementation uses a DMA-coherent backend to ensure data consistency
> +between the CPU and DSP without manual cache maintenance in most cases.
GEM usage?
> +
> +Debugging
> +=========
> +The driver includes extensive dynamic debug support. Enable it via the
> +kernel's dynamic debug control:
> +
> +.. code-block:: bash
> +
> + echo "file drivers/accel/qda/* +p" > /sys/kernel/debug/dynamic_debug/control
> +
> +Testing
> +=======
> +The QDA driver can be exercised using the ``fastrpc_test`` utility from the
> +FastRPC userspace library. Run the test application:
pointer
> +
> +.. code-block:: bash
> +
> + fastrpc_test -d 3 -U 1 -t linux -a v68
> +
> +**Options**
> +
> +``-d domain``
> + Select the DSP domain to run on:
> +
> + * ``0`` — ADSP
> + * ``1`` — MDSP
> + * ``2`` — SDSP
> + * ``3`` — CDSP *(default on targets with CDSP)*
> +
> +``-U unsigned_PD``
> + Select signed or unsigned protection domain:
> +
> + * ``0`` — signed PD
> + * ``1`` — unsigned PD *(default)*
> +
> +``-t target``
> + Target platform: ``android`` or ``linux`` *(default: linux)*
> +
> +``-a arch_version``
> + DSP architecture version, e.g. ``v68``, ``v75`` *(default: v68)*
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 03/15] accel/qda: Add initial QDA DRM accelerator driver
From: Dmitry Baryshkov @ 2026-05-20 14:18 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-3-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:53AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Add the foundational driver files for the Qualcomm DSP Accelerator
> (QDA), a DRM accel driver for Qualcomm DSPs. The driver integrates
> with the DRM accel subsystem (drivers/accel/) and provides:
>
> - A standard /dev/accel/accel* character device node via DRM.
> - GEM-based buffer management with DMA-BUF import/export (PRIME).
> - IOMMU context bank management for per-session memory isolation.
> - Standard DRM IOCTLs for device management and job submission.
>
> qda_drv.c / qda_drv.h: Core DRM driver registration. Defines the
> drm_driver ops table, per-file private state (qda_file_priv), and the
> main device structure (qda_dev) which embeds drm_device.
>
> qda_rpmsg.c / qda_rpmsg.h: RPMsg transport layer. Registers an
> rpmsg_driver matching the "qcom,fastrpc" compatible string. On probe
> it allocates a qda_dev, reads the DSP domain name from the "label" DT
> property, and registers the DRM device.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> drivers/accel/Kconfig | 1 +
> drivers/accel/Makefile | 1 +
> drivers/accel/qda/Kconfig | 30 +++++++++++++
> drivers/accel/qda/Makefile | 10 +++++
> drivers/accel/qda/qda_drv.c | 97 ++++++++++++++++++++++++++++++++++++++++++
> drivers/accel/qda/qda_drv.h | 62 +++++++++++++++++++++++++++
> drivers/accel/qda/qda_rpmsg.c | 99 +++++++++++++++++++++++++++++++++++++++++++
> drivers/accel/qda/qda_rpmsg.h | 13 ++++++
> 8 files changed, 313 insertions(+)
>
> diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig
> index bdf48ccafcf2..74ac0f71bc9d 100644
> --- a/drivers/accel/Kconfig
> +++ b/drivers/accel/Kconfig
> @@ -29,6 +29,7 @@ source "drivers/accel/ethosu/Kconfig"
> source "drivers/accel/habanalabs/Kconfig"
> source "drivers/accel/ivpu/Kconfig"
> source "drivers/accel/qaic/Kconfig"
> +source "drivers/accel/qda/Kconfig"
> source "drivers/accel/rocket/Kconfig"
>
> endif
> diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile
> index 1d3a7251b950..58c08dd5f389 100644
> --- a/drivers/accel/Makefile
> +++ b/drivers/accel/Makefile
> @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/
> obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/
> obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/
> obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/
> +obj-$(CONFIG_DRM_ACCEL_QDA) += qda/
> obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/
> \ No newline at end of file
> diff --git a/drivers/accel/qda/Kconfig b/drivers/accel/qda/Kconfig
> new file mode 100644
> index 000000000000..484d21ff1b55
> --- /dev/null
> +++ b/drivers/accel/qda/Kconfig
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Qualcomm DSP accelerator driver
> +#
> +
> +config DRM_ACCEL_QDA
> + tristate "Qualcomm DSP accelerator"
> + depends on DRM_ACCEL
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on RPMSG
> + help
> + Enables the DRM-based accelerator driver for Qualcomm's Hexagon DSPs.
> + This driver provides a standardized interface for offloading computational
> + tasks to the DSP, including audio processing, sensor offload, computer
> + vision, and AI inference workloads.
> +
> + The driver supports all DSP domains (ADSP, CDSP, SDSP, GDSP) and
> + implements the FastRPC protocol for communication between the application
> + processor and DSP. It integrates with the Linux kernel's Compute
> + Accelerators subsystem (drivers/accel/) and provides a modern alternative
> + to the legacy FastRPC driver found in drivers/misc/.
> +
> + Key features include DMA-BUF interoperability for seamless buffer sharing
Key features of what? Consider distro maintainers reading your help text
in order to identify whether to enable it or not.
> + with other multimedia subsystems, IOMMU-based memory isolation, and
> + standard DRM IOCTLs for device management and job submission.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called qda.
> diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile
> new file mode 100644
> index 000000000000..dbe809067a8b
> --- /dev/null
> +++ b/drivers/accel/qda/Makefile
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Makefile for Qualcomm DSP accelerator driver
> +#
> +
> +obj-$(CONFIG_DRM_ACCEL_QDA) := qda.o
> +
> +qda-y := \
> + qda_drv.o \
> + qda_rpmsg.o
> diff --git a/drivers/accel/qda/qda_drv.c b/drivers/accel/qda/qda_drv.c
> new file mode 100644
> index 000000000000..1c1bab68d445
> --- /dev/null
> +++ b/drivers/accel/qda/qda_drv.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <drm/drm_accel.h>
> +#include <drm/drm_drv.h>
> +#include <drm/drm_file.h>
> +#include <drm/drm_gem.h>
> +#include <drm/drm_ioctl.h>
> +#include <drm/drm_print.h>
> +
> +#include "qda_drv.h"
> +#include "qda_rpmsg.h"
> +
> +static int qda_open(struct drm_device *dev, struct drm_file *file)
> +{
> + struct qda_file_priv *qda_file_priv;
> +
> + qda_file_priv = kzalloc_obj(*qda_file_priv);
> + if (!qda_file_priv)
> + return -ENOMEM;
> +
> + qda_file_priv->qda_dev = qda_dev_from_drm(dev);
> + file->driver_priv = qda_file_priv;
> +
> + return 0;
> +}
> +
> +static void qda_postclose(struct drm_device *dev, struct drm_file *file)
> +{
> + struct qda_file_priv *qda_file_priv = file->driver_priv;
> +
> + kfree(qda_file_priv);
> + file->driver_priv = NULL;
> +}
> +
> +DEFINE_DRM_ACCEL_FOPS(qda_accel_fops);
> +
> +static const struct drm_driver qda_drm_driver = {
> + .driver_features = DRIVER_COMPUTE_ACCEL,
> + .fops = &qda_accel_fops,
> + .open = qda_open,
> + .postclose = qda_postclose,
> + .name = QDA_DRIVER_NAME,
> + .desc = "Qualcomm DSP Accelerator Driver",
> +};
> +
> +struct qda_dev *qda_alloc_device(struct device *dev)
> +{
> + struct qda_dev *qdev;
> +
> + qdev = devm_drm_dev_alloc(dev, &qda_drm_driver, struct qda_dev, drm_dev);
> + if (IS_ERR(qdev))
> + return ERR_CAST(qdev);
> +
> + return qdev;
> +}
> +
> +void qda_unregister_device(struct qda_dev *qdev)
> +{
> + drm_dev_unregister(&qdev->drm_dev);
> +}
> +
> +int qda_register_device(struct qda_dev *qdev)
> +{
> + int ret;
> +
> + ret = drm_dev_register(&qdev->drm_dev, 0);
> + if (ret)
> + drm_err(&qdev->drm_dev, "Failed to register DRM device: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int __init qda_core_init(void)
> +{
> + int ret;
> +
> + ret = qda_rpmsg_register();
> + if (ret)
> + return ret;
> +
> + pr_info("qda: QDA driver initialization complete\n");
> + return 0;
> +}
> +
> +static void __exit qda_core_exit(void)
> +{
> + qda_rpmsg_unregister();
> +}
> +
> +module_init(qda_core_init);
> +module_exit(qda_core_exit);
> +
> +MODULE_AUTHOR("Qualcomm AI Infra Team");
> +MODULE_DESCRIPTION("Qualcomm DSP Accelerator Driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/accel/qda/qda_drv.h b/drivers/accel/qda/qda_drv.h
> new file mode 100644
> index 000000000000..7ba2ef19a411
> --- /dev/null
> +++ b/drivers/accel/qda/qda_drv.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QDA_DRV_H__
> +#define __QDA_DRV_H__
> +
> +#include <linux/device.h>
> +#include <linux/rpmsg.h>
> +#include <linux/types.h>
> +#include <drm/drm_device.h>
> +#include <drm/drm_drv.h>
> +#include <drm/drm_file.h>
> +
> +/* Driver identification */
> +#define QDA_DRIVER_NAME "qda"
> +
> +/**
> + * struct qda_file_priv - Per-process private data for DRM file
> + */
> +struct qda_file_priv {
> + /** @qda_dev: Back-pointer to device structure */
> + struct qda_dev *qda_dev;
> +};
> +
> +/**
> + * struct qda_dev - Main device structure for QDA driver
> + *
> + * The DRM device is embedded as the first member so that container_of()
> + * can recover the qda_dev from any drm_device pointer.
> + */
> +struct qda_dev {
> + /** @drm_dev: Embedded DRM device; recover via qda_dev_from_drm() */
> + struct drm_device drm_dev;
> + /** @rpdev: RPMsg device for communication with the remote processor */
> + struct rpmsg_device *rpdev;
> + /** @dev: Underlying Linux device */
> + struct device *dev;
> + /** @dsp_name: Name of the DSP domain (e.g. "cdsp", "adsp") */
> + const char *dsp_name;
> +};
> +
> +/**
> + * qda_dev_from_drm - Recover qda_dev from an embedded drm_device pointer
> + * @dev: Pointer to the embedded drm_device
> + *
> + * Return: Pointer to the enclosing qda_dev.
> + */
> +static inline struct qda_dev *qda_dev_from_drm(struct drm_device *dev)
> +{
> + return container_of(dev, struct qda_dev, drm_dev);
> +}
> +
> +/* Device allocation (uses devm_drm_dev_alloc internally) */
> +struct qda_dev *qda_alloc_device(struct device *dev);
> +
> +/* Core device lifecycle */
> +int qda_register_device(struct qda_dev *qdev);
> +void qda_unregister_device(struct qda_dev *qdev);
> +
> +#endif /* __QDA_DRV_H__ */
> diff --git a/drivers/accel/qda/qda_rpmsg.c b/drivers/accel/qda/qda_rpmsg.c
> new file mode 100644
> index 000000000000..6eaf1b145f8a
> --- /dev/null
> +++ b/drivers/accel/qda/qda_rpmsg.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/rpmsg.h>
> +#include <drm/drm_print.h>
> +
> +#include "qda_drv.h"
> +#include "qda_rpmsg.h"
> +
> +static struct qda_dev *alloc_and_init_qdev(struct rpmsg_device *rpdev)
Use the prefix uniformly.
> +{
> + struct qda_dev *qdev;
> +
> + qdev = qda_alloc_device(&rpdev->dev);
> + if (IS_ERR(qdev))
> + return qdev;
> +
> + qdev->dev = &rpdev->dev;
> + qdev->rpdev = rpdev;
> + dev_set_drvdata(&rpdev->dev, qdev);
> +
> + return qdev;
> +}
> +
> +static int qda_rpmsg_cb(struct rpmsg_device *rpdev, void *data, int len,
> + void *priv, u32 src)
> +{
> + /* Placeholder: responses will be dispatched here */
> + return 0;
> +}
> +
> +static void qda_rpmsg_remove(struct rpmsg_device *rpdev)
> +{
> + struct qda_dev *qdev = dev_get_drvdata(&rpdev->dev);
> +
> + drm_dev_unplug(&qdev->drm_dev);
> + qdev->rpdev = NULL;
> + qda_unregister_device(qdev);
> + dev_info(qdev->dev, "RPMsg device removed\n");
Drop the spamming. And useless (where it is useless) drm_dbg() / dev_dbg() spamming too.
> +}
> +
> +static int qda_rpmsg_probe(struct rpmsg_device *rpdev)
> +{
> + struct qda_dev *qdev;
> + const char *label;
> + int ret;
> +
> + dev_dbg(&rpdev->dev, "QDA RPMsg probe starting\n");
> +
> + qdev = alloc_and_init_qdev(rpdev);
> + if (IS_ERR(qdev))
> + return PTR_ERR(qdev);
> +
> + ret = of_property_read_string(rpdev->dev.of_node, "label", &label);
> + if (ret) {
> + dev_err(qdev->dev, "Missing 'label' property in DT node: %d\n", ret);
> + return ret;
> + }
> + qdev->dsp_name = label;
Why not just of_property_read_string(...., &qdev->dsp_name)?
> +
> + ret = qda_register_device(qdev);
return qda_register_device();
> + if (ret)
> + return ret;
> +
> + drm_info(&qdev->drm_dev, "QDA RPMsg probe complete for %s\n", qdev->dsp_name);
> + return 0;
> +}
> +
> +static const struct of_device_id qda_rpmsg_id_table[] = {
> + { .compatible = "qcom,fastrpc" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, qda_rpmsg_id_table);
> +
> +static struct rpmsg_driver qda_rpmsg_driver = {
> + .probe = qda_rpmsg_probe,
> + .remove = qda_rpmsg_remove,
> + .callback = qda_rpmsg_cb,
> + .drv = {
> + .name = "qcom,fastrpc",
> + .of_match_table = qda_rpmsg_id_table,
> + },
> +};
> +
> +int qda_rpmsg_register(void)
> +{
> + int ret = register_rpmsg_driver(&qda_rpmsg_driver);
> +
> + if (ret)
> + pr_err("qda: Failed to register RPMsg driver: %d\n", ret);
> +
> + return ret;
> +}
> +
> +void qda_rpmsg_unregister(void)
> +{
> + unregister_rpmsg_driver(&qda_rpmsg_driver);
> +}
Just use module_rpmsg_driver(), drop all the wrappers and module_init()
/ exit().
> diff --git a/drivers/accel/qda/qda_rpmsg.h b/drivers/accel/qda/qda_rpmsg.h
> new file mode 100644
> index 000000000000..5229d834b34b
> --- /dev/null
> +++ b/drivers/accel/qda/qda_rpmsg.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QDA_RPMSG_H__
> +#define __QDA_RPMSG_H__
> +
> +/* RPMsg transport layer registration */
> +int qda_rpmsg_register(void);
> +void qda_rpmsg_unregister(void);
> +
> +#endif /* __QDA_RPMSG_H__ */
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Guenter Roeck @ 2026-05-20 14:18 UTC (permalink / raw)
To: Jihong Min
Cc: Greg Kroah-Hartman, Mathias Nyman, Jonathan Corbet, Shuah Khan,
Mario Limonciello, Basavaraj Natikar, Michal Pecio,
Mario Limonciello, Yaroslav Isakov, linux-usb, linux-hwmon,
linux-doc, linux-pci, linux-kernel
In-Reply-To: <20260519000732.2334711-2-hurryman2212@gmail.com>
On Tue, May 19, 2026 at 09:07:31AM +0900, Jihong Min wrote:
> AMD Promontory 21 (PROM21) xHCI PCI functions use the common xhci-pci
> core for USB operation, but also expose controller-specific sensor data.
> Add a small PROM21 PCI glue driver for AMD 1022:43fc and 1022:43fd
> controllers.
>
> The glue delegates USB host operation to the common xhci-pci core and
> publishes a "hwmon" auxiliary device with parent-provided MMIO data.
> Auxiliary device creation failure is logged but does not fail the xHCI
> probe.
>
> Make the PROM21 glue a hidden Kconfig tristate driven by the user-visible
> SENSORS_PROM21_XHCI option. If sensor support is disabled, generic
> xhci-pci binds PROM21 controllers normally. If sensor support is enabled,
> the glue follows USB_XHCI_PCI.
>
> This keeps the auxiliary device available for a modular sensor driver while
> avoiding a built-in xhci-pci core handing PROM21 controllers to a glue
> driver that is only available as a module during initramfs.
>
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Tested-by: Yaroslav Isakov <yaroslav.isakov@gmail.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
The two patches should be applied together. For now I will assume that
they will both be applied through a usb tree since this patch touches
common usb code.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 1/3] drm/fdinfo: Add "evicted" memory accounting
From: Tvrtko Ursulin @ 2026-05-20 14:19 UTC (permalink / raw)
To: Nicolas Frattaroli, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Boris Brezillon,
Steven Price, Liviu Dudau, Jonathan Corbet, Shuah Khan
Cc: dri-devel, linux-kernel, kernel, linux-doc
In-Reply-To: <20260520-panthor-bo-reclaim-observability-v4-1-a47ab61cb80d@collabora.com>
On 20/05/2026 14:04, Nicolas Frattaroli wrote:
> Currently, there's no way to know for certain how much GPU memory was
> swapped out. The difference between total and resident memory would
> include newly allocated pages, which are not resident, but also aren't
> swapped out.
>
> Add a new drm_gem_object_status so drivers can signal when an object has
> been evicted to swap, and add a new "evicted" counter to
> drm_memory_stats.
>
> Due to how the supported_flags bitmask is determined, the "evicted"
> count won't be printed to fdinfo if there's no swapped out pages.
>
> Reviewed-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> Documentation/gpu/drm-usage-stats.rst | 6 ++++++
> drivers/gpu/drm/drm_file.c | 8 ++++++++
> include/drm/drm_file.h | 2 ++
> include/drm/drm_gem.h | 2 ++
> 4 files changed, 18 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
> index 70b7cfcc194f..ac1dbf52d96d 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -202,6 +202,12 @@ One practical example of this could be the presence of unsignaled fences in a
> GEM buffer reservation object. Therefore, the active category is a subset of the
> resident category.
>
> +- drm-evicted-<region>: <uint> [KiB|MiB]
> +
> +The total size of buffers that have been evicted and are no longer pinned by the
> +device. Only present if there are buffers that are currently evicted, and if the
> +driver implements reporting of this type of memory.
The semantics as tricky to make work in an obvious way.
On one hand the text above is almost exactly the semantics of 'total' -
'resident'. Almost meaning it was resident at some point, but isn't any
more. Whereas raw 'total' - 'resident' can also mean it never has been
instantiated.
You could even have a "workaround" where you report a 'swap' memory
region and then don't need to add anything new to the spec.
Next problem - on paper evicted could be useful to replace driver legacy
keys such as 'amd-evicted-ram'. But that "evicted" is defined as "not in
a the preferred placement". While your evicted is more like "no current
placement" (as in, no GPU accessible backing storage).
Is it possible to find a definition of this new category which makes
sense for different GPUs/drivers, be it integrated or discrete.
Or would simply going for 'drm-total-swap:' (or resident?) work for
panthor? Advantage being it would also work unambiguously for discrete
drivers.
Like the ones which support multiple TTM placements, for example VRAM +
SYSTEM and then next step is swapping out so an extreme example on a
16GiB GPU + 16GiB RAM machine with a 32GiB gfx workload could be like:
drm-total-vram: 32GiB
drm-resident-vram: 16GiB
drm-resident-system: 15GiB
drm-total-swap: 1GiB
Does this look clear enough? Whereas with the "evicted" category it
would be:
drm-total-vram: 32GiB
drm-resident-vram: 16GiB
drm-evicted-vram: 16GiB # portion which got demoted to system RAM
drm-resident-system: 15GiB
drm-evicted-system: 1GiB # portion which got demoted to swap
Where drm-evicted-vram is redundant to "total - resident". And it is
overloaded semantics as it where does evicted go depending on the
GPU/driver/region.
Thoughts, opinions?
Regards,
Tvrtko
> +
> Implementation Details
> ======================
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index ec820686b302..5078172976c0 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -868,6 +868,7 @@ int drm_memory_stats_is_zero(const struct drm_memory_stats *stats)
> stats->private == 0 &&
> stats->resident == 0 &&
> stats->purgeable == 0 &&
> + stats->evicted == 0 &&
> stats->active == 0);
> }
> EXPORT_SYMBOL(drm_memory_stats_is_zero);
> @@ -901,6 +902,10 @@ void drm_print_memory_stats(struct drm_printer *p,
> if (supported_status & DRM_GEM_OBJECT_PURGEABLE)
> drm_fdinfo_print_size(p, prefix, "purgeable", region,
> stats->purgeable);
> +
> + if (supported_status & DRM_GEM_OBJECT_EVICTED)
> + drm_fdinfo_print_size(p, prefix, "evicted", region,
> + stats->evicted);
> }
> EXPORT_SYMBOL(drm_print_memory_stats);
>
> @@ -954,6 +959,9 @@ void drm_show_memory_stats(struct drm_printer *p, struct drm_file *file)
>
> if (s & DRM_GEM_OBJECT_PURGEABLE)
> status.purgeable += add_size;
> +
> + if (s & DRM_GEM_OBJECT_EVICTED)
> + status.evicted += add_size;
> }
> spin_unlock(&file->table_lock);
>
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 6ee70ad65e1f..7e4cb45a52c3 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -500,6 +500,7 @@ void drm_send_event_timestamp_locked(struct drm_device *dev,
> * @resident: Total size of GEM objects backing pages
> * @purgeable: Total size of GEM objects that can be purged (resident and not active)
> * @active: Total size of GEM objects active on one or more engines
> + * @evicted: Total size of GEM objects that have been evicted
> *
> * Used by drm_print_memory_stats()
> */
> @@ -509,6 +510,7 @@ struct drm_memory_stats {
> u64 resident;
> u64 purgeable;
> u64 active;
> + u64 evicted;
> };
>
> enum drm_gem_object_status;
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 86f5846154f7..799588a2762a 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -53,6 +53,7 @@ struct drm_gem_object;
> * @DRM_GEM_OBJECT_RESIDENT: object is resident in memory (ie. not unpinned)
> * @DRM_GEM_OBJECT_PURGEABLE: object marked as purgeable by userspace
> * @DRM_GEM_OBJECT_ACTIVE: object is currently used by an active submission
> + * @DRM_GEM_OBJECT_EVICTED: object is evicted and no longer pinned by driver
> *
> * Bitmask of status used for fdinfo memory stats, see &drm_gem_object_funcs.status
> * and drm_show_fdinfo(). Note that an object can report DRM_GEM_OBJECT_PURGEABLE
> @@ -67,6 +68,7 @@ enum drm_gem_object_status {
> DRM_GEM_OBJECT_RESIDENT = BIT(0),
> DRM_GEM_OBJECT_PURGEABLE = BIT(1),
> DRM_GEM_OBJECT_ACTIVE = BIT(2),
> + DRM_GEM_OBJECT_EVICTED = BIT(3),
> };
>
> /**
>
^ permalink raw reply
* Re: [PATCH 04/15] accel/qda: Add compute bus for QDA context banks
From: Dmitry Baryshkov @ 2026-05-20 14:19 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-4-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:54AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Introduce a custom virtual bus (qda-compute-cb) for managing IOMMU
> context bank (CB) devices used by the QDA driver.
>
> IOMMU context banks are synthetic constructs — they are not real
> platform devices and do not appear as children of a platform bus node
> in the device tree. Using a platform driver to represent them was
> therefore incorrect and introduced a probe-ordering race: device nodes
> were created before the RPMsg channel resources were fully initialized,
> and because probe runs asynchronously, user-space could open a CB
> device and attempt to start a session before the underlying transport
> was ready.
>
> The qda-compute-cb bus solves this by allowing the main QDA driver to
> create CB devices explicitly and under its own control, making their
> lifetime strictly subordinate to the parent qda_dev. The bus provides
> a dma_configure callback that calls of_dma_configure() so that each CB
> device gets its own IOMMU domain derived from its device-tree node,
> enabling per-session memory isolation.
>
> The bus type and the CB device constructor (create_qda_cb_device) are
> exported for use by the QDA memory manager.
>
> A hidden Kconfig symbol (DRM_ACCEL_QDA_COMPUTE_BUS) is introduced and
> automatically selected by DRM_ACCEL_QDA so that the bus initialisation
> runs via postcore_initcall before any QDA device probes.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> drivers/accel/Makefile | 1 +
> drivers/accel/qda/Kconfig | 4 +++
> drivers/accel/qda/Makefile | 2 ++
> drivers/accel/qda/qda_compute_bus.c | 68 +++++++++++++++++++++++++++++++++++++
> include/linux/qda_compute_bus.h | 32 +++++++++++++++++
> 5 files changed, 107 insertions(+)
>
> diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile
> index 58c08dd5f389..9ed843cd293f 100644
> --- a/drivers/accel/Makefile
> +++ b/drivers/accel/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/
> obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/
> obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/
> obj-$(CONFIG_DRM_ACCEL_QDA) += qda/
> +obj-$(CONFIG_DRM_ACCEL_QDA_COMPUTE_BUS) += qda/
Ugh. The previous line should be enough (but don't trust me).
> obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/
> \ No newline at end of file
> diff --git a/drivers/accel/qda/Kconfig b/drivers/accel/qda/Kconfig
> index 484d21ff1b55..2a61a4dda054 100644
> --- a/drivers/accel/qda/Kconfig
> +++ b/drivers/accel/qda/Kconfig
> @@ -3,11 +3,15 @@
> # Qualcomm DSP accelerator driver
> #
>
> +config DRM_ACCEL_QDA_COMPUTE_BUS
> + bool
> +
> config DRM_ACCEL_QDA
> tristate "Qualcomm DSP accelerator"
> depends on DRM_ACCEL
> depends on ARCH_QCOM || COMPILE_TEST
> depends on RPMSG
> + select DRM_ACCEL_QDA_COMPUTE_BUS
> help
> Enables the DRM-based accelerator driver for Qualcomm's Hexagon DSPs.
> This driver provides a standardized interface for offloading computational
> diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile
> index dbe809067a8b..424176f652a5 100644
> --- a/drivers/accel/qda/Makefile
> +++ b/drivers/accel/qda/Makefile
> @@ -8,3 +8,5 @@ obj-$(CONFIG_DRM_ACCEL_QDA) := qda.o
> qda-y := \
> qda_drv.o \
> qda_rpmsg.o
> +
> +obj-$(CONFIG_DRM_ACCEL_QDA_COMPUTE_BUS) += qda_compute_bus.o
> diff --git a/drivers/accel/qda/qda_compute_bus.c b/drivers/accel/qda/qda_compute_bus.c
> new file mode 100644
> index 000000000000..c59d977e924d
> --- /dev/null
> +++ b/drivers/accel/qda/qda_compute_bus.c
> @@ -0,0 +1,68 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/qda_compute_bus.h>
> +#include <linux/slab.h>
> +
> +static int qda_cb_bus_dma_configure(struct device *dev)
> +{
> + return of_dma_configure(dev, dev->of_node, true);
> +}
> +
> +const struct bus_type qda_cb_bus_type = {
> + .name = "qda-compute-cb",
> + .dma_configure = qda_cb_bus_dma_configure,
> +};
> +EXPORT_SYMBOL_GPL(qda_cb_bus_type);
> +
> +static void release_qda_cb_device(struct device *dev)
> +{
> + of_node_put(dev->of_node);
> + kfree(dev);
> +}
> +
> +struct device *create_qda_cb_device(struct device *parent_device, const char *name,
> + u64 dma_mask, struct device_node *of_node)
> +{
> + struct device *dev;
> + int ret;
> +
> + dev = kzalloc_obj(*dev);
> + if (!dev)
> + return ERR_PTR(-ENOMEM);
> +
> + dev->release = release_qda_cb_device;
> + dev->bus = &qda_cb_bus_type;
> + dev->parent = parent_device;
> + dev->coherent_dma_mask = dma_mask;
> + dev->dma_mask = &dev->coherent_dma_mask;
> + dev->of_node = of_node_get(of_node);
> +
> + dev_set_name(dev, "%s", name);
> +
> + ret = device_register(dev);
> + if (ret) {
> + put_device(dev);
> + return ERR_PTR(ret);
> + }
> +
> + return dev;
> +}
> +EXPORT_SYMBOL_GPL(create_qda_cb_device);
> +
> +static int __init qda_cb_bus_init(void)
> +{
> + int err;
> +
> + err = bus_register(&qda_cb_bus_type);
> + if (err < 0) {
> + pr_err("qda-compute-cb bus registration failed: %d\n", err);
> + return err;
> + }
> + return 0;
> +}
> +
> +postcore_initcall(qda_cb_bus_init);
> diff --git a/include/linux/qda_compute_bus.h b/include/linux/qda_compute_bus.h
> new file mode 100644
> index 000000000000..90bf248c7285
> --- /dev/null
> +++ b/include/linux/qda_compute_bus.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QDA_COMPUTE_BUS_H__
> +#define __QDA_COMPUTE_BUS_H__
> +
> +#include <linux/device.h>
> +
> +/*
> + * Custom bus type for QDA compute context bank (CB) devices
> + *
> + * This bus type is used for manually created CB devices that represent
> + * IOMMU context banks. The custom bus allows proper IOMMU configuration
> + * and device management for these virtual devices.
> + */
> +#ifdef CONFIG_DRM_ACCEL_QDA_COMPUTE_BUS
> +extern const struct bus_type qda_cb_bus_type;
> +
> +struct device *create_qda_cb_device(struct device *parent_device, const char *name,
> + u64 dma_mask, struct device_node *of_node);
> +#else
> +static inline struct device *create_qda_cb_device(struct device *parent_device,
> + const char *name, u64 dma_mask,
> + struct device_node *of_node)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +#endif
> +
> +#endif /* __QDA_COMPUTE_BUS_H__ */
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 05/15] iommu: Add QDA compute context bank bus to iommu_buses
From: Dmitry Baryshkov @ 2026-05-20 14:19 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-5-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:55AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Register the QDA compute context bank bus (qda-compute-cb) with the
> IOMMU subsystem by adding it to the iommu_buses[] array.
>
> The QDA driver creates synthetic devices on this bus to represent
> IOMMU context banks (CBs). Each CB device needs its own IOMMU domain
> so that the DSP memory manager can enforce per-session address space
> isolation. Without this registration, the IOMMU subsystem does not
> probe CB devices for IOMMU groups and of_dma_configure() in the bus
> dma_configure callback has no IOMMU domain to attach to.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> drivers/iommu/iommu.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 06/43] KVM: x86/mmu: Bug the VM if gmem attributes are queried to determine max mapping level
From: Sean Christopherson @ 2026-05-20 14:21 UTC (permalink / raw)
To: Fuad Tabba
Cc: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka, kvm,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <CA+EHjTxvLU4XDPXDXYXXWJES1OFQgN8VTRLMgCCNMwBE6Hk8tQ@mail.gmail.com>
On Wed, May 20, 2026, Fuad Tabba wrote:
> On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
> <devnull+ackerleytng.google.com@kernel.org> wrote:
> >
> > From: Ackerley Tng <ackerleytng@google.com>
> >
> > When the maximum mapping level is queried, KVM's MMU lock is held, and
> > while the MMU lock is held, guest_memfd cannot take the
> > filemap_invalidate_lock() to look up the current shared/private state of
> > the gfn, for these reasons:
> >
> > + The MMU lock is a spinlock or rwlock and cannot be held while taking a
> > lock that can sleep.
> > + In guest_memfd's code paths (such as truncate), the
> > filemap_invalidate_lock() is held while taking the MMU lock, and taking
> > the locks in reverse order would introduce a AB-BA deadlock.
> >
> > Currently, the maximum mapping level is only queried from guest_memfd in
> > the process of recovering huge pages, if dirty logging is disabled on a
> > memslot. Dirty logging is not currently supported for guest_memfd, and
> > guest_memfd memslots also cannot be updated.
> >
> > For now, bug the VM if guest_memfd needs to be queried to determine the
> > maximum mapping level. This guard can be removed if/when support is added.
> >
> > Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> > ---
> > arch/x86/kvm/mmu/mmu.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index a80a876ab4ad6..153bcc5369985 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -3357,6 +3357,15 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm, struct kvm_page_fault *fault,
> > max_level = fault->max_level;
> > is_private = fault->is_private;
> > } else {
> > + /*
> > + * Memory attributes cannot be obtained from guest_memfd while
> > + * the MMU lock is held.
> > + */
> > + if (KVM_BUG_ON(static_call_query(__kvm_get_memory_attributes) ==
> > + kvm_gmem_get_memory_attributes, kvm)) {
> > + return 0;
> > + }
> > +
>
> This directly takes the address of kvm_gmem_get_memory_attributes,
> which is only compiled if CONFIG_KVM_GUEST_MEMFD=y. This breaks
> ARCH=i386.
And this bleeds guest_memfd implementation details into places they don't belong.
The right way to deal with this is to use lockdep_assert_not_held() in whatever
code mustn't run with mmu_lock held. E.g.
diff --git virt/kvm/guest_memfd.c virt/kvm/guest_memfd.c
index c9f155c2dc5c..3bea9c1137ef 100644
--- virt/kvm/guest_memfd.c
+++ virt/kvm/guest_memfd.c
@@ -547,6 +547,9 @@ unsigned long kvm_gmem_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
struct inode *inode;
+ /* Comment goes here. */
+ lockdep_assert_not_held(&kvm->mmu_lock);
+
/*
* If this gfn has no associated memslot, there's no chance of the gfn
* being backed by private memory, since guest_memfd must be used for
But I'm confused, because kvm_gmem_get_memory_attributes() doesn't actually take
filemap_invalidate_lock(), so what exactly is the problem?
> > max_level = PG_LEVEL_NUM;
> > is_private = kvm_mem_is_private(kvm, gfn);
> > }
> >
> > --
> > 2.54.0.563.g4f69b47b94-goog
> >
> >
^ permalink raw reply related
* Re: [PATCH 06/15] accel/qda: Create compute context bank devices on QDA compute bus
From: Dmitry Baryshkov @ 2026-05-20 14:23 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-6-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:56AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Introduce the CB (compute context bank) device management layer for the
> QDA driver. Each DSP domain node in the device tree may contain child
> nodes with compatible "qcom,fastrpc-compute-cb", each representing one
> IOMMU context bank. The driver enumerates those child nodes during
> RPMsg probe and creates a corresponding device on the qda-compute-cb
> bus for each one.
>
> The CB devices are created via create_qda_cb_device(), which registers
> them on the qda-compute-cb bus so that the IOMMU subsystem assigns each
> device its own IOMMU domain, enabling per-session address space
> isolation for DSP buffer mapping.
>
> The new qda_cb.c file provides two functions:
>
> qda_create_cb_device()
> Reads the "reg" property from the DT child node to obtain the
> stream ID, constructs a unique device name of the form
> "qda-cb-<dsp>-<sid>", and registers the device on the compute bus.
> A qda_cb_dev entry is allocated and appended to qdev->cb_devs so
> that the list can be walked during teardown.
>
> qda_destroy_cb_device()
> Removes the device from its IOMMU group before calling
> device_unregister(), ensuring the IOMMU domain is released cleanly.
>
> CB devices are populated before the DRM device is registered and
> destroyed before it is unplugged, so no DRM operation can race with
> CB teardown. On probe failure after population, qda_cb_unpopulate()
> is called to clean up any CBs that were successfully created before
> the error.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> drivers/accel/qda/Makefile | 1 +
> drivers/accel/qda/qda_cb.c | 99 +++++++++++++++++++++++++++++++++++++++++++
> drivers/accel/qda/qda_cb.h | 32 ++++++++++++++
> drivers/accel/qda/qda_drv.c | 1 +
> drivers/accel/qda/qda_drv.h | 3 ++
> drivers/accel/qda/qda_rpmsg.c | 12 +++++-
> 6 files changed, 147 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile
> index 424176f652a5..143c9e4e789e 100644
> --- a/drivers/accel/qda/Makefile
> +++ b/drivers/accel/qda/Makefile
> @@ -6,6 +6,7 @@
> obj-$(CONFIG_DRM_ACCEL_QDA) := qda.o
>
> qda-y := \
> + qda_cb.o \
> qda_drv.o \
> qda_rpmsg.o
>
> diff --git a/drivers/accel/qda/qda_cb.c b/drivers/accel/qda/qda_cb.c
> new file mode 100644
> index 000000000000..77caf8438c67
> --- /dev/null
> +++ b/drivers/accel/qda/qda_cb.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> +#include <linux/dma-mapping.h>
> +#include <linux/device.h>
> +#include <linux/of.h>
> +#include <linux/iommu.h>
> +#include <linux/qda_compute_bus.h>
> +#include <linux/slab.h>
> +#include <drm/drm_print.h>
> +#include "qda_drv.h"
> +#include "qda_cb.h"
> +
> +int qda_create_cb_device(struct qda_dev *qdev, struct device_node *cb_node)
> +{
> + struct device *cb_dev;
> + u32 sid = 0;
> + char name[64];
> + struct qda_cb_dev *entry;
> +
> + drm_dbg_driver(&qdev->drm_dev, "Creating CB device for node: %s\n", cb_node->name);
> +
> + of_property_read_u32(cb_node, "reg", &sid);
> +
> + snprintf(name, sizeof(name), "qda-cb-%s-%u", qdev->dsp_name, sid);
> +
> + cb_dev = create_qda_cb_device(qdev->dev, name, DMA_BIT_MASK(32), cb_node);
Wrong prefix. Pass the name format and the params to this function. Use
kasprintf in it.
> + if (IS_ERR(cb_dev)) {
> + drm_err(&qdev->drm_dev, "Failed to create CB device for SID %u: %ld\n",
> + sid, PTR_ERR(cb_dev));
> + return PTR_ERR(cb_dev);
> + }
> +
> + entry = kzalloc_obj(*entry);
> + if (!entry) {
> + device_unregister(cb_dev);
> + return -ENOMEM;
> + }
> +
> + entry->dev = cb_dev;
> + list_add_tail(&entry->node, &qdev->cb_devs);
> +
> + drm_dbg_driver(&qdev->drm_dev, "Successfully created CB device for SID %u\n", sid);
> + return 0;
> +}
> +
> +void qda_cb_unpopulate(struct qda_dev *qdev)
> +{
> + struct qda_cb_dev *entry, *tmp;
> +
> + list_for_each_entry_safe(entry, tmp, &qdev->cb_devs, node) {
> + list_del(&entry->node);
> + qda_destroy_cb_device(entry->dev);
> + kfree(entry);
> + }
> +}
> +
> +int qda_cb_populate(struct qda_dev *qdev, struct device_node *parent_node)
> +{
> + struct device_node *child;
> + int count = 0, success = 0;
> +
> + for_each_child_of_node(parent_node, child) {
> + if (of_device_is_compatible(child, "qcom,fastrpc-compute-cb")) {
> + count++;
> + if (qda_create_cb_device(qdev, child) == 0) {
> + success++;
> + dev_dbg(qdev->dev, "Created CB device for node: %s\n",
> + child->name);
Stop counting successes.
> + } else {
> + dev_err(qdev->dev, "Failed to create CB device for: %s\n",
> + child->name);
Unwind, return error.
> + }
> + }
> + }
> + if (count == 0)
> + return 0;
> + return success > 0 ? 0 : -ENODEV;
> +}
> +
> +void qda_destroy_cb_device(struct device *cb_dev)
> +{
> + struct iommu_group *group;
> +
> + if (!cb_dev) {
How can it be?
> + pr_debug("qda: NULL CB device passed to destroy\n");
> + return;
> + }
> +
> + dev_dbg(cb_dev, "Destroying CB device %s\n", dev_name(cb_dev));
> +
> + group = iommu_group_get(cb_dev);
> + if (group) {
> + dev_dbg(cb_dev, "Removing %s from IOMMU group\n", dev_name(cb_dev));
Be uniform. It's either drm_dbg_foo() or dev_dbg() all over the place.
Don't mix them.
> + iommu_group_remove_device(cb_dev);
> + iommu_group_put(group);
> + }
> +
> + device_unregister(cb_dev);
> +}
> @@ -59,9 +61,17 @@ static int qda_rpmsg_probe(struct rpmsg_device *rpdev)
> }
> qdev->dsp_name = label;
>
> + ret = qda_cb_populate(qdev, rpdev->dev.of_node);
> + if (ret) {
> + dev_err(qdev->dev, "Failed to populate child devices: %d\n", ret);
> + return ret;
> + }
> +
> ret = qda_register_device(qdev);
> - if (ret)
> + if (ret) {
> + qda_cb_unpopulate(qdev);
> return ret;
Unwinding registration?
> + }
>
> drm_info(&qdev->drm_dev, "QDA RPMsg probe complete for %s\n", qdev->dsp_name);
> return 0;
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 07/15] accel/qda: Add memory manager for CB devices
From: Dmitry Baryshkov @ 2026-05-20 14:26 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-7-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:57AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Introduce the QDA memory manager (qda_memory_manager) to track and
> manage the IOMMU devices that back each compute context bank (CB).
>
> Each CB device registered on the qda-compute-cb bus is assigned a
> unique ID via an XArray and wrapped in a qda_iommu_device descriptor
Why do you need an XArray? The number of devices is (more or less)
fixed. You can use a normal array, allocated in the probe function after
counting OF children nodes.
> that records the device pointer and its stream ID. This registry
> allows the driver to look up the correct IOMMU domain for a given
> session when mapping DSP buffers.
>
> The memory manager is initialised in qda_init_device() before CB
> devices are populated and torn down in qda_deinit_device() after they
> are destroyed, ensuring no dangling references remain in the XArray.
>
> qda_cb.c is extended with qda_cb_setup_device(), which is called
> immediately after a CB device is registered on the bus. It allocates
> a qda_iommu_device, registers it with the memory manager, and stores
> it as the CB device's driver data so that qda_destroy_cb_device() can
> retrieve and unregister it during teardown.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> drivers/accel/qda/Makefile | 1 +
> drivers/accel/qda/qda_cb.c | 47 ++++++++++++++
> drivers/accel/qda/qda_drv.c | 34 ++++++++++
> drivers/accel/qda/qda_drv.h | 5 ++
> drivers/accel/qda/qda_memory_manager.c | 111 +++++++++++++++++++++++++++++++++
> drivers/accel/qda/qda_memory_manager.h | 49 +++++++++++++++
> drivers/accel/qda/qda_rpmsg.c | 7 +++
> 7 files changed, 254 insertions(+)
>
> diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile
> index 143c9e4e789e..701fad5ffb50 100644
> --- a/drivers/accel/qda/Makefile
> +++ b/drivers/accel/qda/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_ACCEL_QDA) := qda.o
> qda-y := \
> qda_cb.o \
> qda_drv.o \
> + qda_memory_manager.o \
> qda_rpmsg.o
>
> obj-$(CONFIG_DRM_ACCEL_QDA_COMPUTE_BUS) += qda_compute_bus.o
> diff --git a/drivers/accel/qda/qda_cb.c b/drivers/accel/qda/qda_cb.c
> index 77caf8438c67..6d540bb0ec7b 100644
> --- a/drivers/accel/qda/qda_cb.c
> +++ b/drivers/accel/qda/qda_cb.c
> @@ -8,11 +8,42 @@
> #include <linux/slab.h>
> #include <drm/drm_print.h>
> #include "qda_drv.h"
> +#include "qda_memory_manager.h"
> #include "qda_cb.h"
>
> +static int qda_cb_setup_device(struct qda_dev *qdev, struct device *cb_dev, u32 sid)
> +{
> + struct qda_iommu_device *iommu_dev;
> + int rc;
> +
> + drm_dbg_driver(&qdev->drm_dev, "Setting up CB device %s\n", dev_name(cb_dev));
> +
> + iommu_dev = kzalloc_obj(*iommu_dev);
> + if (!iommu_dev)
> + return -ENOMEM;
> +
> + iommu_dev->dev = cb_dev;
> + iommu_dev->qdev = qdev;
> + iommu_dev->sid = sid;
> +
> + rc = qda_memory_manager_register_device(qdev->iommu_mgr, iommu_dev);
> + if (rc) {
> + drm_err(&qdev->drm_dev, "Failed to register IOMMU device: %d\n", rc);
> + kfree(iommu_dev);
> + return rc;
> + }
> +
> + dev_set_drvdata(cb_dev, iommu_dev);
> +
> + drm_dbg_driver(&qdev->drm_dev, "CB device setup complete - SID: %u\n", sid);
> +
> + return 0;
> +}
> +
> int qda_create_cb_device(struct qda_dev *qdev, struct device_node *cb_node)
> {
> struct device *cb_dev;
> + int ret;
> u32 sid = 0;
> char name[64];
> struct qda_cb_dev *entry;
> @@ -30,6 +61,13 @@ int qda_create_cb_device(struct qda_dev *qdev, struct device_node *cb_node)
> return PTR_ERR(cb_dev);
> }
>
> + ret = qda_cb_setup_device(qdev, cb_dev, sid);
> + if (ret) {
> + drm_err(&qdev->drm_dev, "CB device setup failed: %d\n", ret);
> + device_unregister(cb_dev);
> + return ret;
> + }
> +
> entry = kzalloc_obj(*entry);
> if (!entry) {
> device_unregister(cb_dev);
> @@ -80,6 +118,7 @@ int qda_cb_populate(struct qda_dev *qdev, struct device_node *parent_node)
> void qda_destroy_cb_device(struct device *cb_dev)
> {
> struct iommu_group *group;
> + struct qda_iommu_device *iommu_dev;
>
> if (!cb_dev) {
> pr_debug("qda: NULL CB device passed to destroy\n");
> @@ -88,6 +127,14 @@ void qda_destroy_cb_device(struct device *cb_dev)
>
> dev_dbg(cb_dev, "Destroying CB device %s\n", dev_name(cb_dev));
>
> + iommu_dev = dev_get_drvdata(cb_dev);
> + if (iommu_dev && iommu_dev->qdev && iommu_dev->qdev->iommu_mgr) {
> + dev_dbg(cb_dev, "Unregistering IOMMU device for %s\n",
> + dev_name(cb_dev));
> + qda_memory_manager_unregister_device(iommu_dev->qdev->iommu_mgr,
> + iommu_dev);
> + }
> +
> group = iommu_group_get(cb_dev);
> if (group) {
> dev_dbg(cb_dev, "Removing %s from IOMMU group\n", dev_name(cb_dev));
> diff --git a/drivers/accel/qda/qda_drv.c b/drivers/accel/qda/qda_drv.c
> index 6c20d6a2fc47..0ad5d9873d7e 100644
> --- a/drivers/accel/qda/qda_drv.c
> +++ b/drivers/accel/qda/qda_drv.c
> @@ -57,6 +57,40 @@ struct qda_dev *qda_alloc_device(struct device *dev)
> return qdev;
> }
>
> +static void cleanup_memory_manager(struct qda_dev *qdev)
Prefixes...
> +{
> + if (qdev->iommu_mgr) {
> + qda_memory_manager_exit(qdev->iommu_mgr);
> + kfree(qdev->iommu_mgr);
> + qdev->iommu_mgr = NULL;
> + }
> +}
> +
> +static int init_memory_manager(struct qda_dev *qdev)
> +{
> + qdev->iommu_mgr = kzalloc_obj(*qdev->iommu_mgr);
> + if (!qdev->iommu_mgr)
> + return -ENOMEM;
> +
> + return qda_memory_manager_init(qdev->iommu_mgr);
> +}
> +
> +void qda_deinit_device(struct qda_dev *qdev)
> +{
> + cleanup_memory_manager(qdev);
Ugh, inline all your one-line wrappers.
> +}
> +
> +int qda_init_device(struct qda_dev *qdev)
> +{
> + int ret;
> +
> + ret = init_memory_manager(qdev);
> + if (ret)
> + drm_err(&qdev->drm_dev, "Failed to initialize memory manager: %d\n", ret);
> +
> + return ret;
> +}
> +
> void qda_unregister_device(struct qda_dev *qdev)
> {
> drm_dev_unregister(&qdev->drm_dev);
> diff --git a/drivers/accel/qda/qda_drv.h b/drivers/accel/qda/qda_drv.h
> index 2715f378775d..eb089e586b17 100644
> --- a/drivers/accel/qda/qda_drv.h
> +++ b/drivers/accel/qda/qda_drv.h
> @@ -13,6 +13,7 @@
> #include <drm/drm_device.h>
> #include <drm/drm_drv.h>
> #include <drm/drm_file.h>
> +#include "qda_memory_manager.h"
>
> /* Driver identification */
> #define QDA_DRIVER_NAME "qda"
> @@ -40,6 +41,8 @@ struct qda_dev {
> struct device *dev;
> /** @cb_devs: Compute context-bank (CB) child devices */
> struct list_head cb_devs;
> + /** @iommu_mgr: IOMMU/memory manager instance */
> + struct qda_memory_manager *iommu_mgr;
> /** @dsp_name: Name of the DSP domain (e.g. "cdsp", "adsp") */
> const char *dsp_name;
> };
> @@ -59,6 +62,8 @@ static inline struct qda_dev *qda_dev_from_drm(struct drm_device *dev)
> struct qda_dev *qda_alloc_device(struct device *dev);
>
> /* Core device lifecycle */
> +int qda_init_device(struct qda_dev *qdev);
> +void qda_deinit_device(struct qda_dev *qdev);
> int qda_register_device(struct qda_dev *qdev);
> void qda_unregister_device(struct qda_dev *qdev);
>
> diff --git a/drivers/accel/qda/qda_memory_manager.c b/drivers/accel/qda/qda_memory_manager.c
> new file mode 100644
> index 000000000000..00a9c0ae4224
> --- /dev/null
> +++ b/drivers/accel/qda/qda_memory_manager.c
> @@ -0,0 +1,111 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> +
> +#include <linux/refcount.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/xarray.h>
> +#include <drm/drm_file.h>
> +#include "qda_drv.h"
> +#include "qda_memory_manager.h"
> +
> +static void cleanup_all_memory_devices(struct qda_memory_manager *mem_mgr)
> +{
> + unsigned long index;
> + void *entry;
> +
> + pr_debug("qda: Starting cleanup of all memory devices\n");
pr_debug is a third way to debug. Stop it, please.
> +
> + xa_for_each(&mem_mgr->device_xa, index, entry) {
> + struct qda_iommu_device *iommu_dev = entry;
> +
> + pr_debug("qda: Cleaning up device id=%lu\n", index);
> +
> + xa_erase(&mem_mgr->device_xa, index);
> + kfree(iommu_dev);
> + }
> +
> + pr_debug("qda: Completed cleanup of all memory devices\n");
> +}
> +
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 07/15] accel/qda: Add memory manager for CB devices
From: Dmitry Baryshkov @ 2026-05-20 14:27 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-7-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:57AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Introduce the QDA memory manager (qda_memory_manager) to track and
> manage the IOMMU devices that back each compute context bank (CB).
>
> Each CB device registered on the qda-compute-cb bus is assigned a
> unique ID via an XArray and wrapped in a qda_iommu_device descriptor
> that records the device pointer and its stream ID. This registry
> allows the driver to look up the correct IOMMU domain for a given
> session when mapping DSP buffers.
>
> The memory manager is initialised in qda_init_device() before CB
> devices are populated and torn down in qda_deinit_device() after they
> are destroyed, ensuring no dangling references remain in the XArray.
>
> qda_cb.c is extended with qda_cb_setup_device(), which is called
> immediately after a CB device is registered on the bus. It allocates
> a qda_iommu_device, registers it with the memory manager, and stores
> it as the CB device's driver data so that qda_destroy_cb_device() can
> retrieve and unregister it during teardown.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> drivers/accel/qda/Makefile | 1 +
> drivers/accel/qda/qda_cb.c | 47 ++++++++++++++
> drivers/accel/qda/qda_drv.c | 34 ++++++++++
> drivers/accel/qda/qda_drv.h | 5 ++
> drivers/accel/qda/qda_memory_manager.c | 111 +++++++++++++++++++++++++++++++++
> drivers/accel/qda/qda_memory_manager.h | 49 +++++++++++++++
> drivers/accel/qda/qda_rpmsg.c | 7 +++
> 7 files changed, 254 insertions(+)
>
> @@ -61,14 +62,20 @@ static int qda_rpmsg_probe(struct rpmsg_device *rpdev)
> }
> qdev->dsp_name = label;
>
> + ret = qda_init_device(qdev);
> + if (ret)
> + return ret;
> +
> ret = qda_cb_populate(qdev, rpdev->dev.of_node);
> if (ret) {
> dev_err(qdev->dev, "Failed to populate child devices: %d\n", ret);
> + qda_deinit_device(qdev);
> return ret;
> }
>
> ret = qda_register_device(qdev);
> if (ret) {
> + qda_deinit_device(qdev);
> qda_cb_unpopulate(qdev);
No, this is not how you unwind in the error case in the kernel. Follow
the established patterns.
> return ret;
> }
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 11/43] KVM: guest_memfd: Ensure pages are not in use before conversion
From: Fuad Tabba @ 2026-05-20 14:28 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-11-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Ackerley Tng <ackerleytng@google.com>
>
> When converting memory to private in guest_memfd, it is necessary to ensure
> that the pages are not currently being accessed by any other part of the
> kernel or userspace to avoid any current user writing to guest private
> memory.
>
> guest_memfd checks for unexpected refcounts to determine whether a page is
> still in use. The only expected refcounts after unmapping the range
> requested for conversion are those that are held by guest_memfd itself.
>
> Update the kvm_memory_attributes2 structure to include an error_offset
> field. This allows KVM to report the exact offset where a conversion
> failed to userspace. If the safety check fails, return -EAGAIN and copy
> the error_offset back to userspace so that it can potentially retry the
> operation or handle the failure gracefully.
>
> Suggested-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> Co-developed-by: Vishal Annapurve <vannapurve@google.com>
> Signed-off-by: Vishal Annapurve <vannapurve@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> include/uapi/linux/kvm.h | 3 ++-
> virt/kvm/guest_memfd.c | 65 ++++++++++++++++++++++++++++++++++++++++++++----
> 2 files changed, 62 insertions(+), 6 deletions(-)
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index e6bbf68a83813..0b55258573d3d 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1658,7 +1658,8 @@ struct kvm_memory_attributes2 {
> __u64 size;
> __u64 attributes;
> __u64 flags;
> - __u64 reserved[12];
> + __u64 error_offset;
> + __u64 reserved[11];
> };
>
> #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 91e89b188f583..9d82642a025e9 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -572,9 +572,42 @@ static int kvm_gmem_mas_preallocate(struct ma_state *mas, u64 attributes,
> return mas_preallocate(mas, xa_mk_value(attributes), GFP_KERNEL);
> }
>
> +static bool kvm_gmem_is_safe_for_conversion(struct inode *inode, pgoff_t start,
> + size_t nr_pages, pgoff_t *err_index)
> +{
> + struct address_space *mapping = inode->i_mapping;
> + const int filemap_get_folios_refcount = 1;
> + pgoff_t last = start + nr_pages - 1;
> + struct folio_batch fbatch;
> + bool safe = true;
> + int i;
> +
> + folio_batch_init(&fbatch);
> + while (safe && filemap_get_folios(mapping, &start, last, &fbatch)) {
> +
> + for (i = 0; i < folio_batch_count(&fbatch); ++i) {
> + struct folio *folio = fbatch.folios[i];
> +
> + if (folio_ref_count(folio) !=
> + folio_nr_pages(folio) + filemap_get_folios_refcount) {
> + safe = false;
> + *err_index = folio->index;
> + break;
> + }
> + }
> +
> + folio_batch_release(&fbatch);
> + cond_resched();
> + }
> +
> + return safe;
> +}
> +
> static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
> - size_t nr_pages, uint64_t attrs)
> + size_t nr_pages, uint64_t attrs,
> + pgoff_t *err_index)
> {
> + bool to_private = attrs & KVM_MEMORY_ATTRIBUTE_PRIVATE;
> struct address_space *mapping = inode->i_mapping;
> struct gmem_inode *gi = GMEM_I(inode);
> pgoff_t end = start + nr_pages;
> @@ -588,8 +621,21 @@ static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
>
> mas_init(&mas, mt, start);
> r = kvm_gmem_mas_preallocate(&mas, attrs, start, nr_pages);
> - if (r)
> + if (r) {
> + *err_index = start;
> goto out;
> + }
> +
> + if (to_private) {
> + unmap_mapping_pages(mapping, start, nr_pages, false);
> +
> + if (!kvm_gmem_is_safe_for_conversion(inode, start, nr_pages,
> + err_index)) {
> + mas_destroy(&mas);
> + r = -EAGAIN;
> + goto out;
> + }
> + }
>
> /*
> * From this point on guest_memfd has performed necessary
> @@ -609,9 +655,10 @@ static long kvm_gmem_set_attributes(struct file *file, void __user *argp)
> struct gmem_file *f = file->private_data;
> struct inode *inode = file_inode(file);
> struct kvm_memory_attributes2 attrs;
> + pgoff_t err_index;
> size_t nr_pages;
> pgoff_t index;
> - int i;
> + int i, r;
>
> if (copy_from_user(&attrs, argp, sizeof(attrs)))
> return -EFAULT;
> @@ -635,8 +682,16 @@ static long kvm_gmem_set_attributes(struct file *file, void __user *argp)
>
> nr_pages = attrs.size >> PAGE_SHIFT;
> index = attrs.offset >> PAGE_SHIFT;
> - return __kvm_gmem_set_attributes(inode, index, nr_pages,
> - attrs.attributes);
> + r = __kvm_gmem_set_attributes(inode, index, nr_pages, attrs.attributes,
> + &err_index);
> + if (r) {
> + attrs.error_offset = ((uint64_t)err_index) << PAGE_SHIFT;
> +
> + if (copy_to_user(argp, &attrs, sizeof(attrs)))
> + return -EFAULT;
> + }
> +
> + return r;
> }
>
> static long kvm_gmem_ioctl(struct file *file, unsigned int ioctl,
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH 08/15] accel/qda: Add QUERY IOCTL and QDA UAPI header
From: Dmitry Baryshkov @ 2026-05-20 14:29 UTC (permalink / raw)
To: ekansh.gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <20260519-qda-series-v1-8-b2d984c297f8@oss.qualcomm.com>
On Tue, May 19, 2026 at 11:45:58AM +0530, Ekansh Gupta via B4 Relay wrote:
> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>
> Introduce the DRM_IOCTL_QDA_QUERY IOCTL, which allows user-space to
> identify which DSP domain a given /dev/accel/accel* node represents
> (e.g. "cdsp", "adsp").
>
> include/uapi/drm/qda_accel.h
> Defines the QDA IOCTL command numbers and the associated data
> structures. The header follows the standard DRM UAPI conventions:
> __u8/__u32 types, a C++ extern "C" guard, and GPL-2.0-only WITH
> Linux-syscall-note licensing.
>
> drivers/accel/qda/qda_ioctl.c / qda_ioctl.h
> Implements qda_ioctl_query(), which copies the DSP domain name
> stored in qda_dev.dsp_name into the user-supplied drm_qda_query
> buffer using strscpy().
>
> drivers/accel/qda/qda_drv.c
> Registers the qda_ioctls[] table with the drm_driver so that the
> DRM core dispatches DRM_IOCTL_QDA_QUERY to qda_ioctl_query().
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
> drivers/accel/qda/Makefile | 1 +
> drivers/accel/qda/qda_drv.c | 8 +++++++
> drivers/accel/qda/qda_ioctl.c | 26 +++++++++++++++++++++++
> drivers/accel/qda/qda_ioctl.h | 13 ++++++++++++
> include/uapi/drm/qda_accel.h | 49 +++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 97 insertions(+)
>
> diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile
> index 701fad5ffb50..b658dad35fee 100644
> --- a/drivers/accel/qda/Makefile
> +++ b/drivers/accel/qda/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_ACCEL_QDA) := qda.o
> qda-y := \
> qda_cb.o \
> qda_drv.o \
> + qda_ioctl.o \
> qda_memory_manager.o \
> qda_rpmsg.o
>
> diff --git a/drivers/accel/qda/qda_drv.c b/drivers/accel/qda/qda_drv.c
> index 0ad5d9873d7e..becd831d10be 100644
> --- a/drivers/accel/qda/qda_drv.c
> +++ b/drivers/accel/qda/qda_drv.c
> @@ -8,8 +8,10 @@
> #include <drm/drm_gem.h>
> #include <drm/drm_ioctl.h>
> #include <drm/drm_print.h>
> +#include <drm/qda_accel.h>
>
> #include "qda_drv.h"
> +#include "qda_ioctl.h"
> #include "qda_rpmsg.h"
>
> static int qda_open(struct drm_device *dev, struct drm_file *file)
> @@ -36,11 +38,17 @@ static void qda_postclose(struct drm_device *dev, struct drm_file *file)
>
> DEFINE_DRM_ACCEL_FOPS(qda_accel_fops);
>
> +static const struct drm_ioctl_desc qda_ioctls[] = {
> + DRM_IOCTL_DEF_DRV(QDA_QUERY, qda_ioctl_query, 0),
> +};
> +
> static const struct drm_driver qda_drm_driver = {
> .driver_features = DRIVER_COMPUTE_ACCEL,
> .fops = &qda_accel_fops,
> .open = qda_open,
> .postclose = qda_postclose,
> + .ioctls = qda_ioctls,
> + .num_ioctls = ARRAY_SIZE(qda_ioctls),
> .name = QDA_DRIVER_NAME,
> .desc = "Qualcomm DSP Accelerator Driver",
> };
> diff --git a/drivers/accel/qda/qda_ioctl.c b/drivers/accel/qda/qda_ioctl.c
> new file mode 100644
> index 000000000000..761d3567c33f
> --- /dev/null
> +++ b/drivers/accel/qda/qda_ioctl.c
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> +#include <drm/drm_ioctl.h>
> +#include <drm/qda_accel.h>
> +#include "qda_drv.h"
> +#include "qda_ioctl.h"
> +
> +/**
> + * qda_ioctl_query() - Query DSP device information
> + * @dev: DRM device structure
> + * @data: User-space data (struct drm_qda_query)
> + * @file_priv: DRM file private data
> + *
> + * Return: 0 on success, negative error code on failure
> + */
> +int qda_ioctl_query(struct drm_device *dev, void *data, struct drm_file *file_priv)
> +{
> + struct drm_qda_query *args = data;
> + struct qda_dev *qdev;
> +
> + qdev = qda_dev_from_drm(dev);
> +
> + strscpy(args->dsp_name, qdev->dsp_name, sizeof(args->dsp_name));
> +
> + return 0;
> +}
> diff --git a/drivers/accel/qda/qda_ioctl.h b/drivers/accel/qda/qda_ioctl.h
> new file mode 100644
> index 000000000000..b8fd536a111f
> --- /dev/null
> +++ b/drivers/accel/qda/qda_ioctl.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QDA_IOCTL_H__
> +#define __QDA_IOCTL_H__
> +
> +#include "qda_drv.h"
> +
> +int qda_ioctl_query(struct drm_device *dev, void *data, struct drm_file *file_priv);
> +
> +#endif /* __QDA_IOCTL_H__ */
> diff --git a/include/uapi/drm/qda_accel.h b/include/uapi/drm/qda_accel.h
> new file mode 100644
> index 000000000000..1971a4263065
> --- /dev/null
> +++ b/include/uapi/drm/qda_accel.h
> @@ -0,0 +1,49 @@
> +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QDA_ACCEL_H__
> +#define __QDA_ACCEL_H__
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +/*
> + * QDA IOCTL command numbers
> + *
> + * These define the command numbers for QDA-specific IOCTLs.
> + * They are used with DRM_COMMAND_BASE to create the full IOCTL numbers.
> + */
> +#define DRM_QDA_QUERY 0x00
> +
> +/*
> + * QDA IOCTL definitions
> + *
> + * These macros define the actual IOCTL numbers used by userspace applications.
> + * They combine the command numbers with DRM_COMMAND_BASE and specify the
> + * data structure and direction (read/write) for each IOCTL.
> + */
> +#define DRM_IOCTL_QDA_QUERY DRM_IOR(DRM_COMMAND_BASE + DRM_QDA_QUERY, \
> + struct drm_qda_query)
> +
> +/**
> + * struct drm_qda_query - Device information query structure
> + * @dsp_name: Name of DSP (e.g., "adsp", "cdsp", "cdsp1", "gdsp0", "gdsp1")
> + *
> + * This structure is used with DRM_IOCTL_QDA_QUERY to query device type,
> + * allowing userspace to identify which DSP a device node represents. The
> + * kernel provides the DSP name directly as a null-terminated string.
> + */
> +struct drm_qda_query {
> + __u8 dsp_name[16];
Are you sure that you want to query only the name? No extra options, no
attributes, no hardware capabilities?
> +};
> +
> +#if defined(__cplusplus)
> +}
> +#endif
> +
> +#endif /* __QDA_ACCEL_H__ */
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 12/43] KVM: guest_memfd: Call arch invalidate hooks on conversion
From: Fuad Tabba @ 2026-05-20 14:30 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-12-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Ackerley Tng <ackerleytng@google.com>
>
> When memory in guest_memfd is converted from private to shared, the
> platform-specific state associated with the guest-private pages must be
> invalidated or cleaned up.
>
> Iterate over the folios in the affected range and call the
> kvm_arch_gmem_invalidate() hook for each PFN range. This allows
> architectures to perform necessary teardown, such as updating hardware
> metadata or encryption states, before the pages are transitioned to the
> shared state.
>
> Invoke this helper after indicating to KVM's mmu code that an invalidation
> is in progress to stop in-flight page faults from succeeding.
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Minor nit below, but lgtm.
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> virt/kvm/guest_memfd.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 9d82642a025e9..baf4b88dead1f 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -603,6 +603,42 @@ static bool kvm_gmem_is_safe_for_conversion(struct inode *inode, pgoff_t start,
> return safe;
> }
>
> +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE
> +static void kvm_gmem_invalidate(struct inode *inode, pgoff_t start, pgoff_t end)
> +{
> + struct folio_batch fbatch;
> + pgoff_t next = start;
> + int i;
> +
> + folio_batch_init(&fbatch);
> + while (filemap_get_folios(inode->i_mapping, &next, end - 1, &fbatch)) {
> + for (i = 0; i < folio_batch_count(&fbatch); ++i) {
> + struct folio *folio = fbatch.folios[i];
> + pgoff_t start_index, end_index;
> + kvm_pfn_t start_pfn, end_pfn;
> +
> + start_index = max(start, folio->index);
> + end_index = min(end, folio_next_index(folio));
> + /*
> + * end_index is either in folio or points to
> + * the first page of the next folio. Hence,
> + * all pages in range [start_index, end_index)
> + * are contiguous.
> + */
> + start_pfn = folio_file_pfn(folio, start_index);
> + end_pfn = start_pfn + end_index - start_index;
> +
> + kvm_arch_gmem_invalidate(start_pfn, end_pfn);
> + }
> +
> + folio_batch_release(&fbatch);
> + cond_resched();
> + }
> +}
> +#else
> +static void kvm_gmem_invalidate(struct inode *inode, pgoff_t start, pgoff_t end) {}
> +#endif
> +
> static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
> size_t nr_pages, uint64_t attrs,
> pgoff_t *err_index)
> @@ -643,7 +679,12 @@ static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
> */
>
> kvm_gmem_invalidate_begin(inode, start, end);
> +
> + if (!to_private)
> + kvm_gmem_invalidate(inode, start, end);
> +
> mas_store_prealloc(&mas, xa_mk_value(attrs));
> +
Why the unrelated extra space?
> kvm_gmem_invalidate_end(inode, start, end);
> out:
> filemap_invalidate_unlock(mapping);
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH] kconfig: add optional warnings for changed input values
From: Nicolas Schier @ 2026-05-20 14:31 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Nathan Chancellor, Masahiro Yamada, linux-kbuild, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Thomas Meyer, Miguel Ojeda, linux-doc,
linux-kernel
In-Reply-To: <20260406233001.1-kconfig-warn-changed-input-pengpeng@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]
On Mon, Apr 06, 2026 at 11:06:19PM +0800, Pengpeng Hou wrote:
> When reading .config input, Kconfig stores user-provided values first and
> then resolves the final value after applying dependencies, ranges, and
> other constraints.
>
> If the final value differs from the user's input, Kconfig already tracks
> that state internally, but it does not provide any focused diagnostic to
> show which explicit inputs were adjusted. This is particularly confusing
> for requested values that get forced down by unmet dependencies or clamped
> by ranges.
>
> Add an opt-in diagnostic controlled by KCONFIG_WARN_CHANGED_INPUT.
> Emit the warnings from conf_write() and conf_write_defconfig() after
> value resolution and through the existing message callback path so the
> default behavior stays unchanged and interactive frontends remain usable.
>
> Document the new environment variable and add tests for both olddefconfig
> and savedefconfig.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
Thanks a lot for this patch! I know quite some people waiting for that
feature! Just a minor nit-pick, and two minor issues found from
Sashiko; see below.
[...]
> @@ -759,7 +825,10 @@ int conf_write_defconfig(const char *filename)
> {
> struct symbol *sym;
> struct menu *menu;
> + struct gstr gs = str_new();
> FILE *out;
> + bool warn_changed_input = conf_warn_changed_input_enabled();
> + bool found = false;
nit-picking: I'd favor a more descriptive variable name (e.g.
'changed_input_found'), as I am expecting my future me to have to dig
into conf_warn_changed_input_enabled() what that 'found' might really
mean.
[...]
> @@ -798,6 +870,13 @@ int conf_write_defconfig(const char *filename)
> print_symbol_for_dotconfig(out, sym);
> }
> fclose(out);
> +
> + conf_clear_written_flags();
> +
> + if (found)
> + conf_message("%s", str_get(&gs));
Sashiko complains [1] that conf_message() may truncate the output to
4096 bytes, which can easily be provoked, e.g. by switching ARCH.
[...]
> @@ -809,7 +888,10 @@ int conf_write(const char *name)
> const char *str;
> char tmpname[PATH_MAX + 1], oldname[PATH_MAX + 1];
> char *env;
> + struct gstr gs = str_new();
> bool need_newline = false;
> + bool warn_changed_input = conf_warn_changed_input_enabled();
> + bool found = false;
>
> if (!name)
> name = conf_get_configname();
> @@ -859,6 +941,8 @@ int conf_write(const char *name)
> } else if (!sym_is_choice(sym) &&
> !(sym->flags & SYMBOL_WRITTEN)) {
> sym_calc_value(sym);
> + if (warn_changed_input)
> + conf_append_changed_input_warning(&gs, sym, &found);
> if (!(sym->flags & SYMBOL_WRITE))
> goto next;
Sashiko asks about possibly duplicated warnings:
| Will duplicate warning messages be emitted for symbols that have multiple menu
| entries and are forced off (so SYMBOL_WRITE is not set)?
| Since this skips the rest of the loop via goto next;, the symbol is never
| marked with SYMBOL_WRITTEN (which happens later in the block). When the menu
| traversal encounters the same symbol at its next menu node, it will process it
| again and redundantly append the exact same warning.
But from what I can find in in-tree Kconfigs, we do not have Kconfig symbols
that are accessible from multiple menu entries. But it would be good if
someone else could check that once again.
So, thanks again for this small but great feature!
Tested-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Thanks!
[1]: http://sashiko.dev/#/patchset/20260406233001.1-kconfig-warn-changed-input-pengpeng%40iscas.ac.cn
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/3] drm/panthor: Implement evicted status for GEM objects
From: Boris Brezillon @ 2026-05-20 14:33 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Steven Price, Liviu Dudau, Jonathan Corbet,
Shuah Khan, Tvrtko Ursulin, dri-devel, linux-kernel, kernel,
linux-doc
In-Reply-To: <20260520-panthor-bo-reclaim-observability-v4-2-a47ab61cb80d@collabora.com>
On Wed, 20 May 2026 15:04:49 +0200
Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> For fdinfo to be able to fill its evicted counter with data, panthor
> needs to keep track of whether a GEM object has ever been reclaimed.
> Just checking whether the pages are resident isn't enough, as newly
> allocated objects also won't be resident.
>
> Do this with a new atomic_t member on panthor_gem_object. It's increased
> when an object gets evicted by the shrinker, and saturates at INT_MAX.
> This means that once an object has been evicted at least once, its
> reclaim counter will never return to 0.
>
> Due to this, it's possible to distinguish evicted non-resident pages
> from newly allocated non-resident pages by checking whether
> reclaimed_count is != 0
>
> Use this new member to then set the appropriate DRM_GEM_OBJECT_EVICTED
> status flag for fdinfo.
>
> Also add a new column and status flag to the panthor gems debugfs: the
> column is the number of times an object has been evicted, whereas the
> flag indicates whether it currently is evicted.
>
> Reviewed-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/panthor/panthor_gem.c | 18 ++++++++++++++----
> drivers/gpu/drm/panthor/panthor_gem.h | 10 ++++++++++
> 2 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
> index 13295d7a593d..068aa935c8fc 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.c
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -687,6 +687,8 @@ static void panthor_gem_evict_locked(struct panthor_gem_object *bo)
> if (drm_WARN_ON_ONCE(bo->base.dev, !bo->backing.pages))
> return;
>
> + atomic_add_unless(&bo->reclaimed_count, 1, INT_MAX);
> +
> panthor_gem_dev_map_cleanup_locked(bo);
> panthor_gem_backing_cleanup_locked(bo);
> panthor_gem_update_reclaim_state_locked(bo, NULL);
> @@ -788,6 +790,8 @@ static enum drm_gem_object_status panthor_gem_status(struct drm_gem_object *obj)
>
> if (drm_gem_is_imported(&bo->base) || bo->backing.pages)
> res |= DRM_GEM_OBJECT_RESIDENT;
> + else if (atomic_read(&bo->reclaimed_count))
> + res |= DRM_GEM_OBJECT_EVICTED;
Could we drop that change so we can at least have patch 2 and 3 merged
while the discussion on the fdinfo semantics is going on?
>
> return res;
> }
> @@ -1595,6 +1599,7 @@ static void panthor_gem_debugfs_print_flag_names(struct seq_file *m)
> static const char * const gem_state_flags_names[] = {
> [PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT] = "imported",
> [PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT] = "exported",
> + [PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT] = "evicted",
> };
>
> static const char * const gem_usage_flags_names[] = {
> @@ -1625,6 +1630,7 @@ static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo,
> {
> enum panthor_gem_reclaim_state reclaim_state = bo->reclaim_state;
> unsigned int refcount = kref_read(&bo->base.refcount);
> + int reclaimed_count = atomic_read(&bo->reclaimed_count);
> char creator_info[32] = {};
> size_t resident_size;
> u32 gem_usage_flags = bo->debugfs.flags;
> @@ -1638,16 +1644,20 @@ static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo,
>
> snprintf(creator_info, sizeof(creator_info),
> "%s/%d", bo->debugfs.creator.process_name, bo->debugfs.creator.tgid);
> - seq_printf(m, "%-32s%-16d%-16d%-16zd%-16zd0x%-16lx",
> + seq_printf(m, "%-32s%-16d%-16d%-11d%-16zd%-16zd0x%-16lx",
> creator_info,
> bo->base.name,
> refcount,
> + reclaimed_count,
> bo->base.size,
> resident_size,
> drm_vma_node_start(&bo->base.vma_node));
>
> if (drm_gem_is_imported(&bo->base))
> gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED;
> + else if (!resident_size && reclaimed_count)
> + gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED;
> +
> if (bo->base.dma_buf)
> gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED;
>
> @@ -1671,8 +1681,8 @@ static void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev,
>
> panthor_gem_debugfs_print_flag_names(m);
>
> - seq_puts(m, "created-by global-name refcount size resident-size file-offset state usage label\n");
> - seq_puts(m, "----------------------------------------------------------------------------------------------------------------------------------------------\n");
> + seq_puts(m, "created-by global-name refcount evictions size resident-size file-offset state usage label\n");
> + seq_puts(m, "---------------------------------------------------------------------------------------------------------------------------------------------------------\n");
>
> scoped_guard(mutex, &ptdev->gems.lock) {
> list_for_each_entry(bo, &ptdev->gems.node, debugfs.node) {
> @@ -1680,7 +1690,7 @@ static void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev,
> }
> }
>
> - seq_puts(m, "==============================================================================================================================================\n");
> + seq_puts(m, "=========================================================================================================================================================\n");
> seq_printf(m, "Total size: %zd, Total resident: %zd, Total reclaimable: %zd\n",
> totals.size, totals.resident, totals.reclaimable);
> }
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h
> index ae0491d0b121..56d63137b4eb 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.h
> +++ b/drivers/gpu/drm/panthor/panthor_gem.h
> @@ -19,12 +19,16 @@ struct panthor_vm;
> enum panthor_debugfs_gem_state_flags {
> PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT = 0,
> PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT = 1,
> + PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT = 2,
>
> /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED: GEM BO is PRIME imported. */
> PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT),
>
> /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED: GEM BO is PRIME exported. */
> PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT),
> +
> + /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED: GEM BO is evicted to swap. */
> + PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT),
> };
>
> enum panthor_debugfs_gem_usage_flags {
> @@ -172,6 +176,12 @@ struct panthor_gem_object {
> /** @reclaim_state: Cached reclaim state */
> enum panthor_gem_reclaim_state reclaim_state;
>
> + /**
> + * @reclaimed_count: How many times object has been evicted to swap.
> + * The count saturates at %INT_MAX and will never wrap around to 0.
> + */
> + atomic_t reclaimed_count;
> +
> /**
> * @exclusive_vm_root_gem: Root GEM of the exclusive VM this GEM object
> * is attached to.
>
^ permalink raw reply
* Re: (subset) [PATCH v4 1/1] leds: Introduce the multi_max_intensity sysfs attribute
From: Lee Jones @ 2026-05-20 14:34 UTC (permalink / raw)
To: lee, pavel, Armin Wolf
Cc: linux-kernel, corbet, skhan, linux-leds, linux-doc, wse,
jacek.anaszewski, pobrn, m.tretter
In-Reply-To: <20260509214603.262368-2-W_Armin@gmx.de>
On Sat, 09 May 2026 23:46:03 +0200, Armin Wolf wrote:
> Some multicolor LEDs support global brightness control in hardware,
> meaning that the maximum intensity of the color components is not
> connected to the maximum global brightness. Such LEDs cannot be
> described properly by the current multicolor LED class interface,
> because it assumes that the maximum intensity of each color component
> is described by the maximum global brightness of the LED.
>
> [...]
Applied, thanks!
[1/1] leds: Introduce the multi_max_intensity sysfs attribute
commit: b1a9b7a904af2c793850f83a4801a013a718fc47
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH bpf-next] bpf, docs: add LOAD_AQCUIRE and STORE_RELEASE instructions
From: Alexis Lothoré (eBPF Foundation) @ 2026-05-20 14:36 UTC (permalink / raw)
To: David Vernet, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Jonathan Corbet, Shuah Khan
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, bpf, linux-doc,
linux-kernel, Alexis Lothoré (eBPF Foundation)
Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic
instructions modifiers. Those are currently not described in the
documentation, despite being used in the verifier and the various JIT
compilers supporting them.
Add the missing entries in the instruction set documentation.
Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
.../bpf/standardization/instruction-set.rst | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index 39c74611752b..4f10bcd03150 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -695,22 +695,24 @@ arithmetic operations in the 'imm' field to encode the atomic operation:
*(u64 *)(dst + offset) += src
In addition to the simple atomic operations, there also is a modifier and
-two complex atomic operations:
+four complex atomic operations:
.. table:: Complex atomic operations
=========== ================ ===========================
imm value description
=========== ================ ===========================
- FETCH 0x01 modifier: return old value
- XCHG 0xe0 | FETCH atomic exchange
- CMPXCHG 0xf0 | FETCH atomic compare and exchange
+ FETCH 0x0001 modifier: return old value
+ XCHG 0x00e0 | FETCH atomic exchange
+ CMPXCHG 0x00f0 | FETCH atomic compare and exchange
+ LOAD_ACQ 0x0100 atomic load with barrier
+ STORE_REL 0x0110 atomic store with barrier
=========== ================ ===========================
The ``FETCH`` modifier is optional for simple atomic operations, and
-always set for the complex atomic operations. If the ``FETCH`` flag
-is set, then the operation also overwrites ``src`` with the value that
-was in memory before it was modified.
+always set for the ``XCHG`` and ``CMPXCHG`` complex atomic operations. If
+the ``FETCH`` flag is set, then the operation also overwrites ``src`` with
+the value that was in memory before it was modified.
The ``XCHG`` operation atomically exchanges ``src`` with the value
addressed by ``dst + offset``.
@@ -721,6 +723,11 @@ The ``CMPXCHG`` operation atomically compares the value addressed by
value that was at ``dst + offset`` before the operation is zero-extended
and loaded back to ``R0``.
+The ``LOAD_ACQ`` and ``STORE_REL`` operations implement lighter LOAD and
+STORE memory barriers than full barriers. The corresponding accesses must
+be aligned, but are allowed for any access size (8-bit up to 64-bit
+operations).
+
64-bit immediate instructions
-----------------------------
---
base-commit: ceeb3aa37bff895116944acf4347fcded0b7692d
change-id: 20260520-bpf-insn-doc-756b369ca328
Best regards,
--
Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
^ permalink raw reply related
* Re: [PATCH mm-unstable v17 03/14] mm/khugepaged: rework max_ptes_* handling with helper functions
From: David Hildenbrand (Arm) @ 2026-05-20 14:43 UTC (permalink / raw)
To: Nico Pache
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe, Usama Arif
In-Reply-To: <CAA1CXcCD5ooRJonAVp2LvnoCrQwcs1-NsAYomXbHTVNSe5X0cw@mail.gmail.com>
>> Calculate maximum allowed empty PTEs or PTEs mapping the shared zeropage ... ?
>>
>>> + * PTEs for the given collapse operation.
>>
>> We usually indent here (second line of subject), I think. Same applies to the
>> other doc below.
>
> Hmm tbh I couldn't find a example of what you meant here. There are
> some that put a space between the first sentence and the @ list.
Yeah, we usually try to make it fit in a single line.
But nevermind, leave it as is.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v6 13/43] KVM: guest_memfd: Return early if range already has requested attributes
From: Fuad Tabba @ 2026-05-20 14:44 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-13-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Ackerley Tng <ackerleytng@google.com>
>
> Extract a helper out of kvm_gmem_range_is_private() that checks that a
> range has given attributes.
>
> Optimize setting memory attributes by returning early if all pages in the
> requested range already has the requested attributes.
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> virt/kvm/guest_memfd.c | 33 +++++++++++++++++++++++----------
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index baf4b88dead1f..034b72b4947fb 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -86,6 +86,23 @@ static bool kvm_gmem_is_shared_mem(struct inode *inode, pgoff_t index)
> return !kvm_gmem_is_private_mem(inode, index);
> }
>
> +static bool kvm_gmem_range_has_attributes(struct maple_tree *mt,
> + pgoff_t index, size_t nr_pages,
> + u64 attributes)
> +{
> + pgoff_t end = index + nr_pages - 1;
> + void *entry;
> +
> + lockdep_assert(mt_lock_is_held(mt));
> +
> + mt_for_each(mt, entry, index, end) {
> + if (xa_to_value(entry) != attributes)
> + return false;
> + }
> +
> + return true;
> +}
> +
> static int __kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slot,
> pgoff_t index, struct folio *folio)
> {
> @@ -649,12 +666,15 @@ static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
> pgoff_t end = start + nr_pages;
> struct maple_tree *mt;
> struct ma_state mas;
> - int r;
> + int r = 0;
>
> mt = &gi->attributes;
>
> filemap_invalidate_lock(mapping);
>
> + if (kvm_gmem_range_has_attributes(mt, start, nr_pages, attrs))
> + goto out;
> +
> mas_init(&mas, mt, start);
> r = kvm_gmem_mas_preallocate(&mas, attrs, start, nr_pages);
> if (r) {
> @@ -1140,20 +1160,13 @@ EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gmem_get_pfn);
> static bool kvm_gmem_range_is_private(struct gmem_inode *gi, pgoff_t index,
> size_t nr_pages, struct kvm *kvm, gfn_t gfn)
> {
> - pgoff_t end = index + nr_pages - 1;
> - void *entry;
> -
> if (vm_memory_attributes)
> return kvm_range_has_vm_memory_attributes(kvm, gfn, gfn + nr_pages,
> KVM_MEMORY_ATTRIBUTE_PRIVATE,
> KVM_MEMORY_ATTRIBUTE_PRIVATE);
>
> - mt_for_each(&gi->attributes, entry, index, end) {
> - if (xa_to_value(entry) != KVM_MEMORY_ATTRIBUTE_PRIVATE)
> - return false;
> - }
> -
> - return true;
> + return kvm_gmem_range_has_attributes(&gi->attributes, index, nr_pages,
> + KVM_MEMORY_ATTRIBUTE_PRIVATE);
> }
>
> static long __kvm_gmem_populate(struct kvm *kvm, struct kvm_memory_slot *slot,
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH v4 1/4] Introducing pw_lock() and per-cpu queue & flush work
From: Frederic Weisbecker @ 2026-05-20 14:47 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Leonardo Bras, Jonathan Corbet, Shuah Khan, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, linux-doc, linux-kernel, linux-mm,
linux-rt-devel, Marcelo Tosatti
In-Reply-To: <20260520134832.WS7TrMnu@linutronix.de>
Le Wed, May 20, 2026 at 03:48:32PM +0200, Sebastian Andrzej Siewior a écrit :
> How likely is it, that you you had users before late_initcall()? Also
> can it happen that one of them uses one function to lock and the other
> unlock in this brief window? There is no check if this was used before
> static_branch usage.
Or let alone initialization on the wrong member of the union.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 4/4] slub: apply new pw_queue_on() interface
From: Sebastian Andrzej Siewior @ 2026-05-20 14:53 UTC (permalink / raw)
To: Leonardo Bras
Cc: Jonathan Corbet, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, Frederic Weisbecker, linux-doc, linux-kernel,
linux-mm, linux-rt-devel, Marcelo Tosatti
In-Reply-To: <20260519012754.240804-5-leobras.c@gmail.com>
On 2026-05-18 22:27:50 [-0300], Leonardo Bras wrote:
> @@ -4733,121 +4735,121 @@ void *alloc_from_pcs(struct kmem_cache *s, gfp_t gfp, int node)
>
> /*
> * We assume the percpu sheaves contain only local objects although it's
> * not completely guaranteed, so we verify later.
> */
> if (unlikely(node_requested && node != numa_mem_id())) {
> stat(s, ALLOC_NODE_MISMATCH);
> return NULL;
> }
>
> - if (!local_trylock(&s->cpu_sheaves->lock))
> + if (!pw_trylock_local(&s->cpu_sheaves->lock))
> return NULL;
alloc_from_pcs() can be called from kmalloc_nolock()/ NMI context.
I don't remember why exactly local_trylock_t was introduced here instead
of a per-CPU spinlock_t. But there should be nothing wrong with a
trylock on it from NMI as you do here.
One thing worth noting, on !PREEMPT_RT, spin_trylock() always succeeds
on UP. kmalloc_nolock() checks for it, not sure about other callers.
Sebastian
^ permalink raw reply
* Re: [PATCH v4 3/4] swap: apply new pw_queue_on() interface
From: Sebastian Andrzej Siewior @ 2026-05-20 15:07 UTC (permalink / raw)
To: Leonardo Bras
Cc: Jonathan Corbet, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, Frederic Weisbecker, linux-doc, linux-kernel,
linux-mm, linux-rt-devel, Marcelo Tosatti
In-Reply-To: <20260519012754.240804-4-leobras.c@gmail.com>
On 2026-05-18 22:27:49 [-0300], Leonardo Bras wrote:
after digesting the slub patch,
> @@ -882,38 +879,38 @@ static inline void __lru_add_drain_all(bool force_all_cpus)
> * If the paired barrier is done at any later step, e.g. after the
> * loop, CPU #x will just exit at (C) and miss flushing out all of its
> * added pages.
> */
> WRITE_ONCE(lru_drain_gen, lru_drain_gen + 1);
> smp_mb();
>
> cpumask_clear(&has_mm_work);
> cpumask_clear(&has_bh_work);
> for_each_online_cpu(cpu) {
> - struct work_struct *mm_work = &per_cpu(lru_add_drain_work, cpu);
> + struct pw_struct *mm_pw = &per_cpu(lru_add_drain_pw, cpu);
> struct work_struct *bh_work = &per_cpu(bh_add_drain_work, cpu);
>
> if (cpu_needs_mm_drain(cpu)) {
> - INIT_WORK(mm_work, lru_add_drain_per_cpu);
> - queue_work_on(cpu, mm_percpu_wq, mm_work);
> + INIT_PW(mm_pw, lru_add_drain_per_cpu, cpu);
> + pw_queue_on(cpu, mm_percpu_wq, mm_pw);
> __cpumask_set_cpu(cpu, &has_mm_work);
> }
>
> if (cpu_needs_bh_drain(cpu)) {
> INIT_WORK(bh_work, bh_add_drain_per_cpu);
> queue_work_on(cpu, mm_percpu_wq, bh_work);
> __cpumask_set_cpu(cpu, &has_bh_work);
> }
> }
>
> for_each_cpu(cpu, &has_mm_work)
> - flush_work(&per_cpu(lru_add_drain_work, cpu));
> + pw_flush(&per_cpu(lru_add_drain_pw, cpu));
>
> for_each_cpu(cpu, &has_bh_work)
> flush_work(&per_cpu(bh_add_drain_work, cpu));
Why do we have two iterations here? Is it just a proof of concept that
is not complete yet? I am curious why it is okay/needed to "remove" the
one workqueue but not the other. Maybe the other does not bother as much
as the other does.
But essentially we can't use a spin_lock_t here because due to the
hotpath nature of the code it will kill performance. So instead we do it
anyway but behind a switch so that only those suffer from this that do
not want to suffer from workqueue interruption on a NOHZ full system,
right?
I thought that this improved since commit
ff042f4a9b050 ("mm: lru_cache_disable: replace work queue synchronization with synchronize_rcu")
Did it get worse or was it not entirely gone?
> done:
> mutex_unlock(&lock);
> }
>
> void lru_add_drain_all(void)
> {
Sebastian
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, docs: add LOAD_AQCUIRE and STORE_RELEASE instructions
From: bot+bpf-ci @ 2026-05-20 15:18 UTC (permalink / raw)
To: alexis.lothore, void, ast, daniel, andrii, martin.lau, eddyz87,
memxor, song, yonghong.song, jolsa, corbet, skhan
Cc: ebpf, bastien.curutchet, thomas.petazzoni, bpf, bpf, linux-doc,
linux-kernel, alexis.lothore, ast, andrii, daniel, martin.lau,
eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260520-bpf-insn-doc-v1-1-74d7dada9bfc@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 4336 bytes --]
> diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
> --- a/Documentation/bpf/standardization/instruction-set.rst
> +++ b/Documentation/bpf/standardization/instruction-set.rst
> @@ -695,22 +695,24 @@
> *(u64 *)(dst + offset) += src
>
> In addition to the simple atomic operations, there also is a modifier and
> -two complex atomic operations:
> +four complex atomic operations:
>
> .. table:: Complex atomic operations
>
> =========== ================ ===========================
> imm value description
> =========== ================ ===========================
> - FETCH 0x01 modifier: return old value
> - XCHG 0xe0 | FETCH atomic exchange
> - CMPXCHG 0xf0 | FETCH atomic compare and exchange
> + FETCH 0x0001 modifier: return old value
> + XCHG 0x00e0 | FETCH atomic exchange
> + CMPXCHG 0x00f0 | FETCH atomic compare and exchange
> + LOAD_ACQ 0x0100 atomic load with barrier
> + STORE_REL 0x0110 atomic store with barrier
> =========== ================ ===========================
>
> The ``FETCH`` modifier is optional for simple atomic operations, and
> -always set for the complex atomic operations. If the ``FETCH`` flag
> -is set, then the operation also overwrites ``src`` with the value that
> -was in memory before it was modified.
> +always set for the ``XCHG`` and ``CMPXCHG`` complex atomic operations. If
> +the ``FETCH`` flag is set, then the operation also overwrites ``src`` with
> +the value that was in memory before it was modified.
>
> The ``XCHG`` operation atomically exchanges ``src`` with the value
> addressed by ``dst + offset``.
[ ... ]
> @@ -721,6 +723,11 @@
> value that was at ``dst + offset`` before the operation is zero-extended
> and loaded back to ``R0``.
>
> +The ``LOAD_ACQ`` and ``STORE_REL`` operations implement lighter LOAD and
> +STORE memory barriers than full barriers. The corresponding accesses must
> +be aligned, but are allowed for any access size (8-bit up to 64-bit
> +operations).
Does the LOAD_ACQ documentation need to clarify its non-standard register
semantics? BPF atomic operations are encoded as STX instructions, which
conventionally use dst as the memory base pointer and src as the value
register. However, LOAD_ACQ reverses this pattern by using src as the
memory base pointer and dst as the destination register for the fetched
value, acting like an LDX instruction.
Additionally, should the documentation clarify that the loaded value is
zero-extended into the 64-bit destination register for 8, 16, and 32-bit
accesses? Omitting these details might lead to incorrect implementations
based on standard STX rules.
This contradiction creates specification ambiguity: the documentation
states that LOAD_ACQ and STORE_REL "are allowed for any access size
(8-bit up to 64-bit operations)", but earlier in the document (line 671)
explicitly states "8-bit and 16-bit wide atomic operations are not
supported."
The instruction encoding section (lines 667-671) only defines two size
encodings for ATOMIC mode:
- {ATOMIC, W, STX} for 32-bit operations
- {ATOMIC, DW, STX} for 64-bit operations
No encoding is shown for B (byte/8-bit) or H (half-word/16-bit) with
ATOMIC mode.
If LOAD_ACQ/STORE_REL truly support 8-bit and 16-bit sizes, shouldn't the
encoding section document how B and H size modifiers work with ATOMIC
mode, and line 671 clarify the exception?
Alternatively, if LOAD_ACQ/STORE_REL only support 32-bit and 64-bit sizes
like other atomic operations, should line 728 be corrected to state
"32-bit and 64-bit operations" instead of "8-bit up to 64-bit operations"?
For a standardized instruction set specification used by multiple
implementations (verifier, JIT compilers, potentially other BPF runtimes),
internal contradictions can lead to implementation divergence and
interoperability issues.
> +
> 64-bit immediate instructions
> -----------------------------
>
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26170628668
^ permalink raw reply
* Re: [PATCH v6 14/43] KVM: guest_memfd: Advertise KVM_SET_MEMORY_ATTRIBUTES2 ioctl
From: Fuad Tabba @ 2026-05-20 15:22 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-14-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Ackerley Tng <ackerleytng@google.com>
>
> Introduce KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES to advertise the
> availability of the KVM_SET_MEMORY_ATTRIBUTES2 ioctl.
>
> KVM_SET_MEMORY_ATTRIBUTES2 is a guest_memfd-scoped version of the existing
> KVM_SET_MEMORY_ATTRIBUTES VM ioctl. It allows userspace to manage memory
> attributes, such as KVM_MEMORY_ATTRIBUTE_PRIVATE, directly on a guest_memfd
> file descriptor.
>
> This new version uses struct kvm_memory_attributes2, which adds an
> error_offset field to the output. This allows KVM to return the specific
> offset that triggered an error, which is especially useful for handling
> EAGAIN results caused by transient page reference counts during attribute
> conversions.
>
> Update the KVM API documentation to define the new ioctl and its behavior,
> and add the necessary UAPI definitions and capability checks.
>
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Suggested-by: Michael Roth <michael.roth@amd.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> Documentation/virt/kvm/api.rst | 78 +++++++++++++++++++++++++++++++++++++++++-
> include/uapi/linux/kvm.h | 2 ++
> virt/kvm/kvm_main.c | 5 +++
> 3 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 52bbbb553ce10..55c2701d9ed49 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -117,7 +117,7 @@ description:
> x86 includes both i386 and x86_64.
>
> Type:
> - system, vm, or vcpu.
> + system, vm, vcpu or guest_memfd.
>
> Parameters:
> what parameters are accepted by the ioctl.
> @@ -6361,6 +6361,8 @@ S390:
> Returns -EINVAL if the VM has the KVM_VM_S390_UCONTROL flag set.
> Returns -EINVAL if called on a protected VM.
>
> +.. _KVM_SET_MEMORY_ATTRIBUTES:
> +
> 4.141 KVM_SET_MEMORY_ATTRIBUTES
> -------------------------------
>
> @@ -6553,6 +6555,80 @@ KVM_S390_KEYOP_SSKE
> Sets the storage key for the guest address ``guest_addr`` to the key
> specified in ``key``, returning the previous value in ``key``.
>
> +4.145 KVM_SET_MEMORY_ATTRIBUTES2
> +---------------------------------
> +
> +:Capability: KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES
> +:Architectures: all
> +:Type: guest_memfd ioctl
> +:Parameters: struct kvm_memory_attributes2 (in/out)
> +:Returns: 0 on success, <0 on error
> +
> +Errors:
> +
> + ========== ===============================================================
> + EINVAL The specified `offset` or `size` were invalid (e.g. not
> + page aligned, causes an overflow, or size is zero).
> + EFAULT The parameter address was invalid.
> + EAGAIN Some page within requested range had unexpected refcounts. The
> + offset of the page will be returned in `error_offset`.
> + ENOMEM Ran out of memory trying to track private/shared state
> + ========== ===============================================================
> +
> +KVM_SET_MEMORY_ATTRIBUTES2 is an extension to
> +KVM_SET_MEMORY_ATTRIBUTES that supports returning (writing) values to
> +userspace. The original (pre-extension) fields are shared with
> +KVM_SET_MEMORY_ATTRIBUTES identically.
> +
> +Attribute values are shared with KVM_SET_MEMORY_ATTRIBUTES.
> +
> +::
> +
> + struct kvm_memory_attributes2 {
> + /* in */
> + union {
> + __u64 address;
> + __u64 offset;
> + };
> + __u64 size;
> + __u64 attributes;
> + __u64 flags;
> + /* out */
> + __u64 error_offset;
> + __u64 reserved[11];
> + };
> +
> + #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
> +
> +Set attributes for a range of offsets within a guest_memfd to
> +KVM_MEMORY_ATTRIBUTE_PRIVATE to limit the specified guest_memfd backed
> +memory range for guest_use. Even if KVM_CAP_GUEST_MEMFD_MMAP is
> +supported, after a successful call to set
> +KVM_MEMORY_ATTRIBUTE_PRIVATE, the requested range will not be mappable
> +into host userspace and will only be mappable by the guest.
> +
> +To allow the range to be mappable into host userspace again, call
> +KVM_SET_MEMORY_ATTRIBUTES2 on the guest_memfd again with
> +KVM_MEMORY_ATTRIBUTE_PRIVATE unset.
> +
> +KVM does not directly manipulate the memory contents of pages during
> +attribute updates. However, the process of setting these attributes,
> +which includes operations such as unmapping pages from the host or
> +stage-2 page tables, may result in side effects on memory contents
> +that vary across different trusted firmware implementations.
> +
> +If this ioctl returns -EAGAIN, the offset of the page with unexpected
> +refcounts will be returned in `error_offset`. This can occur if there
> +are transient refcounts on the pages, taken by other parts of the
> +kernel.
> +
> +Userspace is expected to figure out how to remove all known refcounts
> +on the shared pages, such as refcounts taken by get_user_pages(), and
> +try the ioctl again. A possible source of these long term refcounts is
> +if the guest_memfd memory was pinned in IOMMU page tables.
> +
> +See also: :ref: `KVM_SET_MEMORY_ATTRIBUTES`.
> +
> .. _kvm_run:
>
> 5. The kvm_run structure
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 0b55258573d3d..f437fd0f1350c 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -996,6 +996,7 @@ struct kvm_enable_cap {
> #define KVM_CAP_S390_USER_OPEREXEC 246
> #define KVM_CAP_S390_KEYOP 247
> #define KVM_CAP_S390_VSIE_ESAMODE 248
> +#define KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES 249
>
> struct kvm_irq_routing_irqchip {
> __u32 irqchip;
> @@ -1648,6 +1649,7 @@ struct kvm_memory_attributes {
> __u64 flags;
> };
>
> +/* Available with KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES */
> #define KVM_SET_MEMORY_ATTRIBUTES2 _IOWR(KVMIO, 0xd2, struct kvm_memory_attributes2)
>
> struct kvm_memory_attributes2 {
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 4d7bf52b7b717..cec02d68d7039 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4972,6 +4972,11 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> return 1;
> case KVM_CAP_GUEST_MEMFD_FLAGS:
> return kvm_gmem_get_supported_flags(kvm);
> + case KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES:
> + if (vm_memory_attributes)
> + return 0;
> +
> + return kvm_supported_mem_attributes(kvm);
> #endif
> default:
> break;
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Xaver Hugl @ 2026-05-20 15:27 UTC (permalink / raw)
To: Christian König
Cc: Julian Orth, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Sumit Semwal, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, dri-devel,
linux-kernel, linux-media, linaro-mm-sig, linux-doc,
wayland-devel, Michel Dänzer
In-Reply-To: <c9fbfdaf-2a58-4423-8dc5-6e29a88f6293@amd.com>
> In general the answer is yes, userspace needs to take care of inserting fences when wait before signal is used and the work can not be submitted to the HW for some reason.
>
> Currently we only have an IOCTL to insert the signaled dummy fence at some timeline sequence, but it should be trivial as well to insert a signaled fence with an error code.
>
> But the compositor needs to be able to handle that case anyway, because it can be that a malicious or just buggy client just never inserts the fence.
>
> So that a device is hot plugged is not different to just a client not inserting the fence in the first place.
A buggy client can always freeze its own surface, it doesn't need
handling beyond cleaning up properly when the client disconnects.
The hotplug case is different, since currently a well-behaved client
can only attempt to signal the point in the syncobj... but the drm
device is gone, so the ioctl will fail and the client's surface is
frozen, even though it did everything right.
So afaict, whatever new ioctl is added for this will need to be
independent of the drm device, or be special cased not to fail when
the device is removed.
> >> One problem is that only syncfile allows for querying such error codes at the moment, we have patches pending to add that to syncobj as well but we lack a compositor with support for that as userspace client.
> > As long as the error case can be detected with an eventfd,
>
> Yeah that's the problem. The eventfd only tells you if the operation is completed (or at least has materialized).
>
> To query the error you would need to ask the underlying syncobj or syncfile directly.
Issuing an additional ioctl after the eventfd fired for this rare case
wouldn't be particularly nice, but also not difficult. If we'd get
that with the eventfd directly, that would be much better though.
> Ah! I think I got the problem now. You basically want to avoid importing the syncobj because when the wrong device goes away you are busted.
Exactly.
> The reason we didn't considered having the IOCTLs on the FD is because if you don't import them and instead keep them around you can run out file descriptors quite quickly.
>
> When you have an use case where you receive an FD from the client and do a one shot conversion to an eventfd that will probably work, but for keeping them in the long run you need some kind of container for the syncobjs, don't you?
Compositors always run with vastly increased fd limits since they have
to handle a lot of fds for dmabufs alone, so keeping the fd around
wouldn't be an issue for us.
> > A device-independent way to create and use syncobj would still be
> > useful to us though, both to simplify the compositor and to improve
> > the software rendering use cases.
>
> Yeah not sure how to cleanly do that. We could have a dummy /dev/dri/rendersync or something like that, but that would be quite a hack.
I think for userspace it would be less of a hack than searching for a
random drm node that can import it. I'd gladly take another solution
as well though, if there is one.
- Xaver
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox