* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Harsh Prateek Bora @ 2026-06-03 6:31 UTC (permalink / raw)
To: Ritesh Harjani (IBM), Madhavan Srinivasan, Vaibhav Jain,
Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <bjdsw43g.ritesh.list@gmail.com>
On 03/06/26 11:35 am, Ritesh Harjani (IBM) wrote:
> Harsh Prateek Bora <harshpb@linux.ibm.com> writes:
>
>>> amit, can you just post this alone as a separate patch, so that we could
>>> pull it for 7.2 merge?
>>>
>>
>> FWIW, b4 am -P1 <mbox> should fetch this patch alone (and not the entire
>> series), See b4 am --help for more options to select a subset of patches.
>>
>
> I agree, however as an FYI in this case -
> I had few review comments on PATCH-1 here [1] - which along with the
> commit msg changes, also had a code change involved, so IMO, it's still
> a good idea if Amit can test and send an updated patch separately for this -
> to be pulled in for 7.2.
>
> [1]: https://lore.kernel.org/linuxppc-dev/pl2g6xbz.ritesh.list@gmail.com/
>
>
> Replying to Vaibhav comment here so that we can reach to the conclusion
> at one place.
>
>> Hence IMHO, this patch can be marked for stable tree and potential
>> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
>> tag to this patch
>
> I agree, we need not use a fixes tag then. So, we shall mark this
> with v6.10 tag then.
>
> Cc: stable@vger.kernel.org # v6.10+
>
> (I calculated this based on when Power11 was added:
> git tag --contains c2ed087ed35ca | grep -E "^v" |head -1
> v6.10
> )
Thanks for help with this, Ritesh!
>
> -ritesh
>
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Ritesh Harjani @ 2026-06-03 6:05 UTC (permalink / raw)
To: Harsh Prateek Bora, Madhavan Srinivasan, Vaibhav Jain,
Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <56c84e26-69ed-433b-baaf-7b53acc60391@linux.ibm.com>
Harsh Prateek Bora <harshpb@linux.ibm.com> writes:
>> amit, can you just post this alone as a separate patch, so that we could
>> pull it for 7.2 merge?
>>
>
> FWIW, b4 am -P1 <mbox> should fetch this patch alone (and not the entire
> series), See b4 am --help for more options to select a subset of patches.
>
I agree, however as an FYI in this case -
I had few review comments on PATCH-1 here [1] - which along with the
commit msg changes, also had a code change involved, so IMO, it's still
a good idea if Amit can test and send an updated patch separately for this -
to be pulled in for 7.2.
[1]: https://lore.kernel.org/linuxppc-dev/pl2g6xbz.ritesh.list@gmail.com/
Replying to Vaibhav comment here so that we can reach to the conclusion
at one place.
> Hence IMHO, this patch can be marked for stable tree and potential
> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
> tag to this patch
I agree, we need not use a fixes tag then. So, we shall mark this
with v6.10 tag then.
Cc: stable@vger.kernel.org # v6.10+
(I calculated this based on when Power11 was added:
git tag --contains c2ed087ed35ca | grep -E "^v" |head -1
v6.10
)
-ritesh
^ permalink raw reply
* [PATCH v4 2/2] arm64: kernel: Disable CNP on HiSilicon HIP09
From: Zeng Heng @ 2026-06-03 6:20 UTC (permalink / raw)
To: will, vladimir.murzin, xuwei5, broonie, ryan.roberts, corbet,
catalin.marinas, oupton, kevin.brodsky, maz, yeoreum.yun, skhan,
yangyicong, thuth, kuninori.morimoto.gx, lucaswei, lpieralisi,
miko.lenczewski, mark.rutland, james.clark
Cc: wangkefeng.wang, linux-arm-kernel, linux-kernel, linux-doc,
zengheng4
In-Reply-To: <20260603062025.1504083-1-zengheng@huaweicloud.com>
From: Zeng Heng <zengheng4@huawei.com>
HiSilicon HIP09 implements TLB entry matching behavior that deviates
from the ARM architecture specification when the CNP (Common not Private)
bit is set in TTBRx_ELx.
When TTBRx.CNP=1, TLB entries may be incorrectly shared between CPU
cores, leading to TLB conflicts and stale mappings. This affects
coherency and can result in incorrect translations.
Add the hardware erratum workaround (Hisilicon erratum 162100125) to
disable CNP on affected HIP09 cores.
Co-developed-by: Tong Tiangen <tongtiangen@huawei.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
---
Documentation/arch/arm64/silicon-errata.rst | 2 ++
arch/arm64/Kconfig | 16 ++++++++++++++++
arch/arm64/kernel/cpu_errata.c | 6 ++++--
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 211119ce7adc..cd50059edb85 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -284,6 +284,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip09 | #162100801 | HISILICON_ERRATUM_162100801 |
+----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip09 | #162100125 | HISILICON_ERRATUM_162100125 |
++----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
+----------------+-----------------+-----------------+-----------------------------+
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index f297517a83b9..75638e37883d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1273,6 +1273,22 @@ config HISILICON_ERRATUM_162100801
If unsure, say Y.
+config HISILICON_ERRATUM_162100125
+ bool "Hisilicon erratum 162100125"
+ default y
+ select ARM64_WORKAROUND_DISABLE_CNP
+ help
+ On HiSilicon HIP09, TLB entry matching behavior when CNP
+ (TTBRx.CNP=1) is enabled differs from the ARM architecture
+ specification.
+
+ TLB entries may be incorrectly shared between CPUs, potentially
+ causing TLB conflicts and stale mappings.
+
+ Disable CNP support for affected HiSilicon HIP09 cores.
+
+ If unsure, say Y.
+
config QCOM_FALKOR_ERRATUM_1003
bool "Falkor E1003: Incorrect translation due to ASID change"
default y
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 08eb9d6545d1..310e6f120992 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -612,6 +612,9 @@ static const struct midr_range erratum_ac04_cpu_23_list[] = {
static const struct midr_range cnp_erratum_cpus[] = {
#ifdef CONFIG_NVIDIA_CARMEL_CNP_ERRATUM
MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL),
+#endif
+#ifdef CONFIG_HISILICON_ERRATUM_162100125
+ MIDR_ALL_VERSIONS(MIDR_HISI_HIP09),
#endif
{},
};
@@ -812,8 +815,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
#endif
#ifdef CONFIG_ARM64_WORKAROUND_DISABLE_CNP
{
- /* NVIDIA Carmel */
- .desc = "NVIDIA Carmel CNP erratum",
+ .desc = "NVIDIA Carmel CNP erratum, or Hisilicon erratum 162100125",
.capability = ARM64_WORKAROUND_DISABLE_CNP,
ERRATA_MIDR_RANGE_LIST(cnp_erratum_cpus),
},
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Zeng Heng @ 2026-06-03 6:20 UTC (permalink / raw)
To: will, vladimir.murzin, xuwei5, broonie, ryan.roberts, corbet,
catalin.marinas, oupton, kevin.brodsky, maz, yeoreum.yun, skhan,
yangyicong, thuth, kuninori.morimoto.gx, lucaswei, lpieralisi,
miko.lenczewski, mark.rutland, james.clark
Cc: wangkefeng.wang, linux-arm-kernel, linux-kernel, linux-doc,
zengheng4
From: Zeng Heng <zengheng4@huawei.com>
v3: https://lore.kernel.org/all/20260601112000.1145391-1-zengheng@huaweicloud.com/
v2: https://lore.kernel.org/all/20260529063132.766491-1-zengheng@huaweicloud.com/
v1: https://lore.kernel.org/all/20260526015720.206854-1-zengheng@huaweicloud.com/
Changes in v4:
- Keep orthogonality for CONFIG_NVIDIA_CARMEL_CNP_ERRATUM and
CONFIG_HISILICON_ERRATUM_162100125 within the cnp_erratum_cpus array.
Changes in v3:
- Keep CONFIG_ARM64_WORKAROUND_DISABLE_CNP config and generalise
ARM64_WORKAROUND_DISABLE_CNP capability.
Changes in v2:
- Unify CNP disable workaround into ARM64_WORKAROUND_DISABLE_CNP
Zeng Heng (2):
arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
arm64: kernel: Disable CNP on HiSilicon HIP09
Documentation/arch/arm64/silicon-errata.rst | 2 ++
arch/arm64/Kconfig | 20 ++++++++++++++++++++
arch/arm64/include/asm/cpucaps.h | 4 ++--
arch/arm64/kernel/cpu_errata.c | 21 ++++++++++++++++-----
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/tools/cpucaps | 2 +-
6 files changed, 42 insertions(+), 9 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v4 1/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Zeng Heng @ 2026-06-03 6:20 UTC (permalink / raw)
To: will, vladimir.murzin, xuwei5, broonie, ryan.roberts, corbet,
catalin.marinas, oupton, kevin.brodsky, maz, yeoreum.yun, skhan,
yangyicong, thuth, kuninori.morimoto.gx, lucaswei, lpieralisi,
miko.lenczewski, mark.rutland, james.clark
Cc: wangkefeng.wang, linux-arm-kernel, linux-kernel, linux-doc,
zengheng4
In-Reply-To: <20260603062025.1504083-1-zengheng@huaweicloud.com>
From: Zeng Heng <zengheng4@huawei.com>
The NVIDIA Carmel CNP erratum is not the only case requiring CNP to be
disabled. Abstract this into a common WORKAROUND_DISABLE_CNP capability
to facilitate adding errata for future chips and reduce duplicate
checks in has_useable_cnp().
This serves as a prerequisite for the subsequent Hisilicon erratum
162100125.
Suggested-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/Kconfig | 4 ++++
arch/arm64/include/asm/cpucaps.h | 4 ++--
arch/arm64/kernel/cpu_errata.c | 15 ++++++++++++---
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/tools/cpucaps | 2 +-
5 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fe60738e5943..f297517a83b9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1315,9 +1315,13 @@ config QCOM_FALKOR_ERRATUM_E1041
If unsure, say Y.
+config ARM64_WORKAROUND_DISABLE_CNP
+ bool
+
config NVIDIA_CARMEL_CNP_ERRATUM
bool "NVIDIA Carmel CNP: CNP on Carmel semantically different than ARM cores"
default y
+ select ARM64_WORKAROUND_DISABLE_CNP
help
If CNP is enabled on Carmel cores, non-sharable TLBIs on a core will not
invalidate shared TLB entries installed by a different core, as it would
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index d0d3cdd5763c..25c61cda901c 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -58,8 +58,8 @@ cpucap_is_possible(const unsigned int cap)
return IS_ENABLED(CONFIG_ARM64_ERRATUM_2658417);
case ARM64_WORKAROUND_CAVIUM_23154:
return IS_ENABLED(CONFIG_CAVIUM_ERRATUM_23154);
- case ARM64_WORKAROUND_NVIDIA_CARMEL_CNP:
- return IS_ENABLED(CONFIG_NVIDIA_CARMEL_CNP_ERRATUM);
+ case ARM64_WORKAROUND_DISABLE_CNP:
+ return IS_ENABLED(CONFIG_ARM64_WORKAROUND_DISABLE_CNP);
case ARM64_WORKAROUND_REPEAT_TLBI:
return IS_ENABLED(CONFIG_ARM64_WORKAROUND_REPEAT_TLBI);
case ARM64_WORKAROUND_SPECULATIVE_SSBS:
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 5377e4c2eba2..08eb9d6545d1 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -608,6 +608,15 @@ static const struct midr_range erratum_ac04_cpu_23_list[] = {
};
#endif
+#ifdef CONFIG_ARM64_WORKAROUND_DISABLE_CNP
+static const struct midr_range cnp_erratum_cpus[] = {
+#ifdef CONFIG_NVIDIA_CARMEL_CNP_ERRATUM
+ MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL),
+#endif
+ {},
+};
+#endif
+
const struct arm64_cpu_capabilities arm64_errata[] = {
#ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
{
@@ -801,12 +810,12 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
1, 0),
},
#endif
-#ifdef CONFIG_NVIDIA_CARMEL_CNP_ERRATUM
+#ifdef CONFIG_ARM64_WORKAROUND_DISABLE_CNP
{
/* NVIDIA Carmel */
.desc = "NVIDIA Carmel CNP erratum",
- .capability = ARM64_WORKAROUND_NVIDIA_CARMEL_CNP,
- ERRATA_MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL),
+ .capability = ARM64_WORKAROUND_DISABLE_CNP,
+ ERRATA_MIDR_RANGE_LIST(cnp_erratum_cpus),
},
#endif
#ifdef CONFIG_ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6d53bb15cf7b..20c5f24f74a9 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1785,7 +1785,7 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
if (is_kdump_kernel())
return false;
- if (cpus_have_cap(ARM64_WORKAROUND_NVIDIA_CARMEL_CNP))
+ if (cpus_have_cap(ARM64_WORKAROUND_DISABLE_CNP))
return false;
return has_cpuid_feature(entry, scope);
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 811c2479e82d..9b85a84f6fd4 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -120,7 +120,7 @@ WORKAROUND_CAVIUM_TX2_219_PRFM
WORKAROUND_CAVIUM_TX2_219_TVM
WORKAROUND_CLEAN_CACHE
WORKAROUND_DEVICE_LOAD_ACQUIRE
-WORKAROUND_NVIDIA_CARMEL_CNP
+WORKAROUND_DISABLE_CNP
WORKAROUND_PMUV3_IMPDEF_TRAPS
WORKAROUND_QCOM_FALKOR_E1003
WORKAROUND_QCOM_ORYON_CNTVOFF
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 11/15] accel/qda: Add PRIME DMA-BUF import support
From: Ekansh Gupta @ 2026-06-03 6:11 UTC (permalink / raw)
To: Christian König, Oded Gabbay, Jonathan Corbet, Shuah Khan,
Joerg Roedel, Will Deacon, Robin Murphy, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Sumit Semwal
Cc: Bharath Kumar, Chenna Kesava Raju, srini, dmitry.baryshkov,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <3dddb7e8-5837-4038-9823-ce419cb49ec2@amd.com>
On 19-05-2026 12:25, Christian König wrote:
> On 5/19/26 08:16, Ekansh Gupta via B4 Relay wrote:
>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>
>> Allow user-space to import DMA-BUF file descriptors from other
>> subsystems (GPU, camera, video) into the QDA driver via the standard
>> DRM PRIME interface.
>>
>> qda_prime.c
>> Implements qda_gem_prime_import(), which is set as the driver's
>> .gem_prime_import callback. On import it:
>> 1. Short-circuits self-import: if the dma_buf was exported by this
>> device and is not itself an import, the existing GEM object is
>> returned with an incremented reference count.
>> 2. Attaches to the dma_buf and maps it with DMA_BIDIRECTIONAL via
>> dma_buf_map_attachment_unlocked(), obtaining an sg_table whose
>> DMA addresses are IOMMU virtual addresses in the CB device's
>> address space.
>> 3. Calls qda_memory_manager_alloc() to record the IOMMU mapping and
>> encode the SID in the upper 32 bits of the DMA address, matching
>> the convention used for natively allocated buffers.
>>
>> qda_prime_fd_to_handle() wraps drm_gem_prime_fd_to_handle() under
>> qdev->import_lock, storing the calling file_priv in
>> qdev->current_import_file_priv so that qda_gem_prime_import() can
>> retrieve it (the .gem_prime_import callback does not receive
>> file_priv directly).
>>
>> qda_gem.c
>> qda_gem_free_object() is extended to handle the imported-buffer
>> teardown path: unmap the sg_table, detach from the dma_buf, and
>> release the dma_buf reference.
>> qda_gem_mmap_obj() rejects mmap requests on imported objects.
>>
>> qda_memory_manager.c
>> qda_memory_manager_map_imported() records the IOMMU-mapped DMA
>> address from the first sg entry (the IOMMU maps the buffer as a
>> contiguous range) and encodes the SID prefix.
>
> No it doesn't.
I see, it does not guarantee or enforce contiguous IOMMU mapping. I'll
fix the commit text.>
>> qda_memory_manager_free() skips the DMA free path for imported
>> buffers since the memory is owned by the exporter.
>>
>> 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 | 12 ++-
>> drivers/accel/qda/qda_drv.h | 4 +
>> drivers/accel/qda/qda_gem.c | 25 ++++-
>> drivers/accel/qda/qda_gem.h | 8 ++
>> drivers/accel/qda/qda_memory_manager.c | 47 ++++++++-
>> drivers/accel/qda/qda_prime.c | 184 +++++++++++++++++++++++++++++++++
>> drivers/accel/qda/qda_prime.h | 18 ++++
>> 8 files changed, 295 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile
>> index a46ddceecfc5..fb092e56d7f3 100644
>> --- a/drivers/accel/qda/Makefile
>> +++ b/drivers/accel/qda/Makefile
>> @@ -12,6 +12,7 @@ qda-y := \
>> qda_ioctl.o \
>> qda_memory_dma.o \
>> qda_memory_manager.o \
>> + qda_prime.o \
>> qda_rpmsg.o
>>
>> obj-$(CONFIG_DRM_ACCEL_QDA_COMPUTE_BUS) += qda_compute_bus.o
>> diff --git a/drivers/accel/qda/qda_drv.c b/drivers/accel/qda/qda_drv.c
>> index c9b9e56dcb28..ef8bd573b836 100644
>> --- a/drivers/accel/qda/qda_drv.c
>> +++ b/drivers/accel/qda/qda_drv.c
>> @@ -7,10 +7,12 @@
>> #include <drm/drm_file.h>
>> #include <drm/drm_gem.h>
>> #include <drm/drm_ioctl.h>
>> +#include <drm/drm_prime.h>
>> #include <drm/drm_print.h>
>> #include <drm/qda_accel.h>
>>
>> #include "qda_drv.h"
>> +#include "qda_prime.h"
>> #include "qda_ioctl.h"
>> #include "qda_rpmsg.h"
>>
>> @@ -64,6 +66,8 @@ static const struct drm_driver qda_drm_driver = {
>> .postclose = qda_postclose,
>> .ioctls = qda_ioctls,
>> .num_ioctls = ARRAY_SIZE(qda_ioctls),
>> + .gem_prime_import = qda_gem_prime_import,
>> + .prime_fd_to_handle = qda_prime_fd_to_handle,
>> .name = QDA_DRIVER_NAME,
>> .desc = "Qualcomm DSP Accelerator Driver",
>> };
>> @@ -100,6 +104,7 @@ static int init_memory_manager(struct qda_dev *qdev)
>>
>> void qda_deinit_device(struct qda_dev *qdev)
>> {
>> + mutex_destroy(&qdev->import_lock);
>> cleanup_memory_manager(qdev);
>> }
>>
>> @@ -107,9 +112,14 @@ int qda_init_device(struct qda_dev *qdev)
>> {
>> int ret;
>>
>> + mutex_init(&qdev->import_lock);
>> + qdev->current_import_file_priv = NULL;
>> +
>> ret = init_memory_manager(qdev);
>> - if (ret)
>> + if (ret) {
>> drm_err(&qdev->drm_dev, "Failed to initialize memory manager: %d\n", ret);
>> + mutex_destroy(&qdev->import_lock);
>> + }
>>
>> return ret;
>> }
>> diff --git a/drivers/accel/qda/qda_drv.h b/drivers/accel/qda/qda_drv.h
>> index 8a7d647ac8fc..96ce4135e2d9 100644
>> --- a/drivers/accel/qda/qda_drv.h
>> +++ b/drivers/accel/qda/qda_drv.h
>> @@ -47,6 +47,10 @@ struct qda_dev {
>> struct list_head cb_devs;
>> /** @iommu_mgr: IOMMU/memory manager instance */
>> struct qda_memory_manager *iommu_mgr;
>> + /** @import_lock: Lock protecting prime import context */
>> + struct mutex import_lock;
>> + /** @current_import_file_priv: Current file_priv during prime import */
>> + struct drm_file *current_import_file_priv;
>> /** @dsp_name: Name of the DSP domain (e.g. "cdsp", "adsp") */
>> const char *dsp_name;
>> };
>> diff --git a/drivers/accel/qda/qda_gem.c b/drivers/accel/qda/qda_gem.c
>> index 568b3c2e64b7..9e1ac7582d0c 100644
>> --- a/drivers/accel/qda/qda_gem.c
>> +++ b/drivers/accel/qda/qda_gem.c
>> @@ -9,6 +9,7 @@
>> #include "qda_gem.h"
>> #include "qda_memory_manager.h"
>> #include "qda_memory_dma.h"
>> +#include "qda_prime.h"
>>
>> static void setup_vma_flags(struct vm_area_struct *vma)
>> {
>> @@ -25,8 +26,20 @@ void qda_gem_free_object(struct drm_gem_object *gem_obj)
>> struct qda_gem_obj *qda_gem_obj = to_qda_gem_obj(gem_obj);
>> struct qda_dev *qdev = qda_dev_from_drm(gem_obj->dev);
>>
>> - if (qda_gem_obj->virt && qdev->iommu_mgr)
>> - qda_memory_manager_free(qdev->iommu_mgr, qda_gem_obj);
>> + if (qda_gem_obj->is_imported) {
>> + if (qda_gem_obj->attachment && qda_gem_obj->sgt)
>> + dma_buf_unmap_attachment_unlocked(qda_gem_obj->attachment,
>> + qda_gem_obj->sgt, DMA_BIDIRECTIONAL);
>> + if (qda_gem_obj->attachment)
>> + dma_buf_detach(qda_gem_obj->dma_buf, qda_gem_obj->attachment);
>> + if (qda_gem_obj->dma_buf)
>> + dma_buf_put(qda_gem_obj->dma_buf);
>> + if (qda_gem_obj->iommu_dev && qdev->iommu_mgr)
>> + qda_memory_manager_free(qdev->iommu_mgr, qda_gem_obj);
>> + } else {
>> + if (qda_gem_obj->virt && qdev->iommu_mgr)
>> + qda_memory_manager_free(qdev->iommu_mgr, qda_gem_obj);
>> + }
>>
>> drm_gem_object_release(gem_obj);
>> kfree(qda_gem_obj);
>> @@ -44,6 +57,10 @@ int qda_gem_mmap_obj(struct drm_gem_object *drm_obj, struct vm_area_struct *vma)
>> struct qda_gem_obj *qda_gem_obj = to_qda_gem_obj(drm_obj);
>> int ret;
>>
>> + /* Imported dma-buf objects must be mmap'd through the exporter, not the importer */
>> + if (qda_gem_obj->is_imported)
>> + return -EINVAL;
>> +
>> /* Reset vm_pgoff for DMA mmap */
>> vma->vm_pgoff = 0;
>>
>> @@ -143,6 +160,10 @@ struct drm_gem_object *qda_gem_create_object(struct drm_device *drm_dev,
>> qda_gem_obj = qda_gem_alloc_object(drm_dev, aligned_size);
>> if (IS_ERR(qda_gem_obj))
>> return ERR_CAST(qda_gem_obj);
>> + qda_gem_obj->is_imported = false;
>> + qda_gem_obj->dma_buf = NULL;
>> + qda_gem_obj->attachment = NULL;
>> + qda_gem_obj->sgt = NULL;
>>
>> ret = qda_memory_manager_alloc(iommu_mgr, qda_gem_obj, file_priv);
>> if (ret) {
>> diff --git a/drivers/accel/qda/qda_gem.h b/drivers/accel/qda/qda_gem.h
>> index bb18f8155aa4..0878f57715f6 100644
>> --- a/drivers/accel/qda/qda_gem.h
>> +++ b/drivers/accel/qda/qda_gem.h
>> @@ -22,12 +22,20 @@ struct qda_gem_obj {
>> struct drm_gem_object base;
>> /** @iommu_dev: IOMMU context bank device that performed the allocation */
>> struct qda_iommu_device *iommu_dev;
>> + /** @dma_buf: Reference to imported dma_buf */
>> + struct dma_buf *dma_buf;
>> + /** @attachment: DMA buf attachment */
>> + struct dma_buf_attachment *attachment;
>> + /** @sgt: Scatter-gather table */
>> + struct sg_table *sgt;
>> /** @virt: Kernel virtual address of the allocated DMA memory */
>> void *virt;
>> /** @dma_addr: DMA address (with SID encoded in upper 32 bits) */
>> dma_addr_t dma_addr;
>> /** @size: Size of the buffer in bytes */
>> size_t size;
>> + /** @is_imported: True if buffer is imported, false if allocated */
>> + bool is_imported;
>> };
>>
>> /**
>> diff --git a/drivers/accel/qda/qda_memory_manager.c b/drivers/accel/qda/qda_memory_manager.c
>> index 82111275f420..d2aa0e0e65f5 100644
>> --- a/drivers/accel/qda/qda_memory_manager.c
>> +++ b/drivers/accel/qda/qda_memory_manager.c
>> @@ -202,6 +202,41 @@ static struct qda_iommu_device *get_or_assign_iommu_device(struct qda_memory_man
>> return NULL;
>> }
>>
>> +static int qda_memory_manager_map_imported(struct qda_memory_manager *mem_mgr,
>> + struct qda_gem_obj *gem_obj,
>> + struct qda_iommu_device *iommu_dev)
>> +{
>> + struct scatterlist *sg;
>> + dma_addr_t dma_addr;
>> +
>> + if (!gem_obj->is_imported || !gem_obj->sgt || !iommu_dev) {
>> + drm_err(gem_obj->base.dev, "Invalid parameters for imported buffer mapping\n");
>> + return -EINVAL;
>> + }
>> +
>> + sg = gem_obj->sgt->sgl;
>> + if (!sg) {
>> + drm_err(gem_obj->base.dev, "Invalid scatter-gather list for imported buffer\n");
>> + return -EINVAL;
>> + }
>> +
>> + gem_obj->iommu_dev = iommu_dev;
>> +
>> + /*
>> + * After dma_buf_map_attachment_unlocked(), sg_dma_address() returns the
>> + * IOMMU virtual address, not the physical address. The IOMMU maps the
>> + * entire buffer as a contiguous range in the IOMMU address space even if
>> + * the underlying physical memory is non-contiguous. Therefore the first
>> + * sg entry's DMA address is the start of the complete contiguous
>> + * IOMMU-mapped range and is sufficient to describe the buffer to the DSP.
>> + */
>> + dma_addr = sg_dma_address(sg);
>> + dma_addr += ((u64)iommu_dev->sid << 32);
>> + gem_obj->dma_addr = dma_addr;
>
> That handling here is completely broken since it assumes that the exporter maps the buffer as contigious range.
>
> But that's in no way guaranteed.
I'll collect more details and will try to implement this in the right
way, maybe by iterating the full sg_table.>
> Regards,
> Christian.
>
>> +
>> + return 0;
>> +}
>> +
>> /**
>> * qda_memory_manager_alloc() - Allocate memory for a GEM object
>> * @mem_mgr: Pointer to memory manager
>> @@ -237,7 +272,11 @@ int qda_memory_manager_alloc(struct qda_memory_manager *mem_mgr, struct qda_gem_
>> return -ENOMEM;
>> }
>>
>> - ret = qda_dma_alloc(selected_dev, gem_obj, size);
>> + if (gem_obj->is_imported)
>> + ret = qda_memory_manager_map_imported(mem_mgr, gem_obj, selected_dev);
>> + else
>> + ret = qda_dma_alloc(selected_dev, gem_obj, size);
>> +
>> if (ret) {
>> drm_err(gem_obj->base.dev, "Allocation failed: size=%zu, device_id=%u, ret=%d\n",
>> size, selected_dev->id, ret);
>> @@ -262,6 +301,12 @@ void qda_memory_manager_free(struct qda_memory_manager *mem_mgr, struct qda_gem_
>> return;
>> }
>>
>> + if (gem_obj->is_imported) {
>> + drm_dbg_driver(gem_obj->base.dev,
>> + "Freed imported buffer tracking (no DMA free needed)\n");
>> + return;
>> + }
>> +
>> qda_dma_free(gem_obj);
>> }
>>
>> diff --git a/drivers/accel/qda/qda_prime.c b/drivers/accel/qda/qda_prime.c
>> new file mode 100644
>> index 000000000000..acb0ac8c40fd
>> --- /dev/null
>> +++ b/drivers/accel/qda/qda_prime.c
>> @@ -0,0 +1,184 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> +#include <drm/drm_gem.h>
>> +#include <drm/drm_prime.h>
>> +#include <drm/drm_print.h>
>> +#include <linux/slab.h>
>> +#include <linux/dma-mapping.h>
>> +#include "qda_drv.h"
>> +#include "qda_gem.h"
>> +#include "qda_prime.h"
>> +#include "qda_memory_manager.h"
>> +
>> +static struct drm_gem_object *check_own_buffer(struct drm_device *dev, struct dma_buf *dma_buf)
>> +{
>> + struct drm_gem_object *existing_gem;
>> +
>> + /* Only safe to access priv if this dma-buf was exported by this device */
>> + if (!drm_gem_is_prime_exported_dma_buf(dev, dma_buf))
>> + return NULL;
>> +
>> + existing_gem = dma_buf->priv;
>> + if (existing_gem->dev != dev)
>> + return NULL;
>> +
>> + if (to_qda_gem_obj(existing_gem)->is_imported)
>> + return NULL;
>> +
>> + drm_gem_object_get(existing_gem);
>> + return existing_gem;
>> +}
>> +
>> +static struct qda_iommu_device *get_iommu_device_for_import(struct qda_dev *qdev,
>> + struct drm_file **file_priv_out)
>> +{
>> + struct drm_file *file_priv;
>> + struct qda_file_priv *qda_file_priv;
>> + struct qda_iommu_device *iommu_dev = NULL;
>> + int ret;
>> +
>> + file_priv = qdev->current_import_file_priv;
>> + *file_priv_out = file_priv;
>> +
>> + if (!file_priv || !file_priv->driver_priv)
>> + return NULL;
>> +
>> + qda_file_priv = (struct qda_file_priv *)file_priv->driver_priv;
>> + iommu_dev = qda_file_priv->assigned_iommu_dev;
>> +
>> + if (!iommu_dev) {
>> + ret = qda_memory_manager_assign_device(qdev->iommu_mgr, file_priv);
>> + if (ret) {
>> + drm_err(&qdev->drm_dev, "Failed to assign IOMMU device: %d\n", ret);
>> + return NULL;
>> + }
>> +
>> + iommu_dev = qda_file_priv->assigned_iommu_dev;
>> + }
>> +
>> + return iommu_dev;
>> +}
>> +
>> +static int setup_dma_buf_mapping(struct qda_gem_obj *qda_gem_obj, struct dma_buf *dma_buf,
>> + struct device *attach_dev, struct qda_dev *qdev)
>> +{
>> + struct dma_buf_attachment *attachment;
>> + struct sg_table *sgt;
>> + int ret;
>> +
>> + attachment = dma_buf_attach(dma_buf, attach_dev);
>> + if (IS_ERR(attachment)) {
>> + ret = PTR_ERR(attachment);
>> + drm_err(&qdev->drm_dev, "Failed to attach dma_buf: %d\n", ret);
>> + return ret;
>> + }
>> + qda_gem_obj->attachment = attachment;
>> +
>> + sgt = dma_buf_map_attachment_unlocked(attachment, DMA_BIDIRECTIONAL);
>> + if (IS_ERR(sgt)) {
>> + ret = PTR_ERR(sgt);
>> + drm_err(&qdev->drm_dev, "Failed to map dma_buf attachment: %d\n", ret);
>> + dma_buf_detach(dma_buf, attachment);
>> + return ret;
>> + }
>> + qda_gem_obj->sgt = sgt;
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * qda_gem_prime_import() - Import a DMA-BUF as a GEM object
>> + * @dev: DRM device structure
>> + * @dma_buf: DMA-BUF to import
>> + *
>> + * Return: Pointer to the imported GEM object on success, ERR_PTR on failure
>> + */
>> +struct drm_gem_object *qda_gem_prime_import(struct drm_device *dev, struct dma_buf *dma_buf)
>> +{
>> + struct qda_dev *qdev = qda_dev_from_drm(dev);
>> + struct qda_gem_obj *qda_gem_obj;
>> + struct drm_file *file_priv;
>> + struct qda_iommu_device *iommu_dev;
>> + struct drm_gem_object *existing_gem;
>> + size_t aligned_size;
>> + int ret;
>> +
>> + if (!qdev->iommu_mgr) {
>> + drm_err(dev, "Invalid iommu_mgr\n");
>> + return ERR_PTR(-ENODEV);
>> + }
>> +
>> + existing_gem = check_own_buffer(dev, dma_buf);
>> + if (existing_gem)
>> + return existing_gem;
>> +
>> + iommu_dev = get_iommu_device_for_import(qdev, &file_priv);
>> + if (!iommu_dev || !iommu_dev->dev) {
>> + drm_err(dev, "No IOMMU device assigned for prime import\n");
>> + return ERR_PTR(-ENODEV);
>> + }
>> +
>> + drm_dbg_driver(dev, "Using IOMMU device %u for prime import\n", iommu_dev->id);
>> +
>> + aligned_size = PAGE_ALIGN(dma_buf->size);
>> + qda_gem_obj = qda_gem_alloc_object(dev, aligned_size);
>> + if (IS_ERR(qda_gem_obj))
>> + return ERR_CAST(qda_gem_obj);
>> +
>> + qda_gem_obj->is_imported = true;
>> + qda_gem_obj->dma_buf = dma_buf;
>> + qda_gem_obj->virt = NULL;
>> + qda_gem_obj->iommu_dev = iommu_dev;
>> +
>> + get_dma_buf(dma_buf);
>> +
>> + ret = setup_dma_buf_mapping(qda_gem_obj, dma_buf, iommu_dev->dev, qdev);
>> + if (ret)
>> + goto err_put_dma_buf;
>> +
>> + ret = qda_memory_manager_alloc(qdev->iommu_mgr, qda_gem_obj, file_priv);
>> + if (ret) {
>> + drm_err(dev, "Failed to allocate IOMMU mapping: %d\n", ret);
>> + goto err_unmap;
>> + }
>> +
>> + drm_dbg_driver(dev, "Prime import completed successfully size=%zu\n", aligned_size);
>> + return &qda_gem_obj->base;
>> +
>> +err_unmap:
>> + dma_buf_unmap_attachment_unlocked(qda_gem_obj->attachment,
>> + qda_gem_obj->sgt, DMA_BIDIRECTIONAL);
>> + dma_buf_detach(dma_buf, qda_gem_obj->attachment);
>> +err_put_dma_buf:
>> + dma_buf_put(dma_buf);
>> + qda_gem_cleanup_object(qda_gem_obj);
>> + return ERR_PTR(ret);
>> +}
>> +
>> +/**
>> + * qda_prime_fd_to_handle() - Convert a PRIME fd to a GEM handle
>> + * @dev: DRM device structure
>> + * @file_priv: DRM file private data
>> + * @prime_fd: File descriptor of the PRIME buffer
>> + * @handle: Output GEM handle
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>> +int qda_prime_fd_to_handle(struct drm_device *dev, struct drm_file *file_priv,
>> + int prime_fd, u32 *handle)
>> +{
>> + struct qda_dev *qdev = qda_dev_from_drm(dev);
>> + int ret;
>> +
>> + mutex_lock(&qdev->import_lock);
>> + qdev->current_import_file_priv = file_priv;
>> +
>> + ret = drm_gem_prime_fd_to_handle(dev, file_priv, prime_fd, handle);
>> +
>> + qdev->current_import_file_priv = NULL;
>> + mutex_unlock(&qdev->import_lock);
>> +
>> + return ret;
>> +}
>> +
>> +MODULE_IMPORT_NS("DMA_BUF");
>> diff --git a/drivers/accel/qda/qda_prime.h b/drivers/accel/qda/qda_prime.h
>> new file mode 100644
>> index 000000000000..9b3850d54fa7
>> --- /dev/null
>> +++ b/drivers/accel/qda/qda_prime.h
>> @@ -0,0 +1,18 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#ifndef __QDA_PRIME_H__
>> +#define __QDA_PRIME_H__
>> +
>> +#include <drm/drm_device.h>
>> +#include <drm/drm_file.h>
>> +#include <drm/drm_gem.h>
>> +#include <linux/dma-buf.h>
>> +
>> +struct drm_gem_object *qda_gem_prime_import(struct drm_device *dev, struct dma_buf *dma_buf);
>> +int qda_prime_fd_to_handle(struct drm_device *dev, struct drm_file *file_priv,
>> + int prime_fd, u32 *handle);
>> +
>> +#endif /* __QDA_PRIME_H__ */
>>
>> --
>> 2.34.1
>>
>>
>
^ permalink raw reply
* [PATCH v2] cpufreq: Documentation: fix freq_step description
From: Pengjie Zhang @ 2026-06-03 5:56 UTC (permalink / raw)
To: rafael, viresh.kumar, corbet, skhan
Cc: linux-pm, linux-doc, linux-kernel, linuxarm, zhanjie9, prime.zeng,
wanghuiqiang, xuwei5, lihuisong, zhenglifeng1, yubowen8,
zhangpengjie2, wangzhi12, zhongqiu.han
The conservative governor documentation incorrectly states that setting
freq_step to 0 will use the default 5% frequency step. In reality, since
at least commit 8e677ce83bf4 ("[CPUFREQ] conservative: fixup governor to
function more like ondemand logic"), freq_step=0 has always caused the
governor to skip frequency updates entirely.
Correct the documentation to reflect the actual behavior: freq_step=0
disables frequency changes by the governor entirely.
Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation")
Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
---
Changes in v2:
- Update commit message to reference the correct historical commit
8e677ce83bf4 instead of b9170836d1aa, as the original implementation
had asymmetric behavior for freq_step=0 (suggested by Zhongqiu Han).
- Link to v1:https://lore.kernel.org/all/20260529111122.3321645-1-zhangpengjie2@huawei.com/
---
Documentation/admin-guide/pm/cpufreq.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
index dbe6d23a5d67..98c724d49047 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -586,8 +586,8 @@ This governor exposes the following tunables:
100 (5 by default).
This is how much the frequency is allowed to change in one go. Setting
- it to 0 will cause the default frequency step (5 percent) to be used
- and setting it to 100 effectively causes the governor to periodically
+ it to 0 disables frequency changes by the governor entirely and setting
+ it to 100 effectively causes the governor to periodically
switch the frequency between the ``scaling_min_freq`` and
``scaling_max_freq`` policy limits.
--
2.33.0
^ permalink raw reply related
* Re: [PATCH 08/15] accel/qda: Add QUERY IOCTL and QDA UAPI header
From: Ekansh Gupta @ 2026-06-03 5:51 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <m4zo2nkxtl5yeyo7riuata6r5saflmdgqf37cz2g2ezrwhk53m@mnad6bb7n3ik>
On 20-05-2026 19:59, Dmitry Baryshkov wrote:
> 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?
There are plans to extend this ioctl to support DSP capabilities and few
other query options, but as per my understanding, I don't need to add
reserved IOCTLs in drm case and I can extend it in future. Please
correct me if my understanding is wrong and I should add reserved fields.
Copying the statement from the doc[1].
"Note that drm_ioctl() automatically zero-extends structures, hence make
sure you can add more stuff at the end, i.e. don’t put a variable sized
array there."
[1]
https://www.kernel.org/doc/html/v7.0/gpu/drm-uapi.html#ioctl-support-on-device-nodes>
>> +};
>> +
>> +#if defined(__cplusplus)
>> +}
>> +#endif
>> +
>> +#endif /* __QDA_ACCEL_H__ */
>>
>> --
>> 2.34.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH 07/15] accel/qda: Add memory manager for CB devices
From: Ekansh Gupta @ 2026-06-03 5:46 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <a6n2qquynwzlquzqmnmjmkg6vkrldj42muuejwzln5wna2qmhi@ki2slzuyt5qw>
On 20-05-2026 19:57, Dmitry Baryshkov wrote:
> 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.
Okay, I see your point and the same you highlighted on previous patch.
I'll update this.>
>> return ret;
>> }
>>
>> --
>> 2.34.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH 07/15] accel/qda: Add memory manager for CB devices
From: Ekansh Gupta @ 2026-06-03 5:44 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <sbktzorprxvo5625zkqwjgsaj723xtbsgzyypbnbgdbbxdgnnh@do5rprsx4oxr>
On 20-05-2026 19:56, Dmitry Baryshkov wrote:
> 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.
Normal array should be fine here, I'll check and remove this.>
>> 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...
ack>
>> +{
>> + 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.
ack>
>> +}
>> +
>> +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.
ack>
>> +
>> + 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");
>> +}
>> +
>
^ permalink raw reply
* Re: [PATCH 06/15] accel/qda: Create compute context bank devices on QDA compute bus
From: Ekansh Gupta @ 2026-06-03 5:39 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <f527lflctqyqjrotd2qerlx4oikg6st6u2seqsjw6u5krkqrab@uhw33gnkp5c7>
On 20-05-2026 19:53, Dmitry Baryshkov wrote:
> 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.
ack>
>> + 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.
>
ack>> + }
>> + }
>> + }
>> + 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?
I'll remove this.>
>> + 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.
ack>
>> + 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?
did I miss something here? The intention to free up the CB devices in
case the device registration fails.>
>> + }
>>
>> drm_info(&qdev->drm_dev, "QDA RPMsg probe complete for %s\n", qdev->dsp_name);
>> return 0;
>>
>> --
>> 2.34.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH 04/15] accel/qda: Add compute bus for QDA context banks
From: Ekansh Gupta @ 2026-06-03 5:28 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <gnlpw4ijwtjv43nhcv5iirhjnuc7dntx5vucdrhnxeyznyxa5x@t65o5owldu5s>
On 20-05-2026 19:49, Dmitry Baryshkov wrote:
> 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).
I was seeing build failures if I don't add this. Took it as a reference
from host1x driver and recent iris patch.>
>> 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
>>
>>
>
^ permalink raw reply
* Re: [PATCH 03/15] accel/qda: Add initial QDA DRM accelerator driver
From: Ekansh Gupta @ 2026-06-03 5:26 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <wbrrredwk2id5ntjlvxhk66uxxa6elwbqg2sj2jmrydz7ss4qz@hsvwcj4iocsu>
On 20-05-2026 19:48, Dmitry Baryshkov wrote:
> 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.
ack>
>> + 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.
>
ack>> +{
>> + 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.
ack>
>> +}
>> +
>> +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();
ack>
>> + 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().
I'll check and update this.>
>> 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
>>
>>
>
^ permalink raw reply
* Re: [PATCH 02/15] accel/qda: Add QDA driver documentation
From: Ekansh Gupta @ 2026-06-03 5:22 UTC (permalink / raw)
To: Tomeu Vizoso, Dmitry Baryshkov
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: <CAPsqS2Tt0JbHhJLHBsbJ2YfZW913WNfoSXpSa+8TD1T9CV8V3g@mail.gmail.com>
On 20-05-2026 21:17, Tomeu Vizoso wrote:
> On Wed, May 20, 2026 at 4:12 PM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> 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.
>
> We have been getting submissions lately that don't fulfill that
> requirement so I will point to the precise part of the documentation
> that explains it:
>
> https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements
>
> For an example of a submissions that complies, see:
>
> https://lore.kernel.org/dri-devel/20260114-thames-v2-0-e94a6636e050@tomeuvizoso.net/
>
> Most importantly, notice how the proposed Thames Mesa driver generates
> machine code for all the hardware units, and doesn't use any blob for
> that.
>
I believe QDA checks all boxes for accel, as there is available
opensource userspace, opensource QAIC compiler for IDL compilation and
LLVM supports hexagon arch.
I'll try adding these details as well.
Thanks!> Regards,
>
> Tomeu
>
>>> +
>>> +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 02/15] accel/qda: Add QDA driver documentation
From: Ekansh Gupta @ 2026-06-03 5:19 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <paiohsil5pmvm7cf6jxrhaj2225bgvlt3scrag4x6gbkyosow5@l4tbakbnxcvo>
On 20-05-2026 19:42, Dmitry Baryshkov wrote:
> 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?
I'll add more details for this, this is specifically required when
persistent type of DSP mappings are required.>
> Would the driver benefit from using GPUVM?
I'm not exactly sure how this will fit in here, I'll check this and get
back.>
>> +
>> +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.
ack>
>> +
>> +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?
I'll add the details here.>
>> +
>> +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
ack.>
>> +
>> +.. 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
>>
>>
>
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Harsh Prateek Bora @ 2026-06-03 5:10 UTC (permalink / raw)
To: Madhavan Srinivasan, Vaibhav Jain, Ritesh Harjani, Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <72ef4cdb-8d9e-4319-9c94-b9a46a6f6194@linux.ibm.com>
On 03/06/26 10:03 am, Madhavan Srinivasan wrote:
>
> On 6/3/26 9:03 AM, Vaibhav Jain wrote:
>> Hi Ritesh, thanks for looking into this patch. My responses to your
>> review comments inline below.
>>
>> Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:
>>
>>> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>>>
>>>> So, we would still want to prioritize the whole series
>>>> instead of just this one patch.
>>>>
>>> Patch-1 could go as a bug fix even in 7.1-rc6 (or maybe with 7.2
>>> bug fixes). - Maddy?
>>>
>>> So, you may want to add a fixes tag and maybe even cc stable if you are
>>> seeing this issue from older kernels maybe when nestedv2 got introduced?
>> This isnt a 'bug fix' per-se but rather strengthening of compat mode
>> checks so that any non compatible PVR being used by the VMM can be
>> caught early. The hypervisor anyway ultimately prevents non-compatible
>> PVRs from being used by the VMM. So there isnt a bug thats being fixed
>> in this patch.
>>
>> The rest of the patch series builds on top of this patch to advertise
>> the available compatible PVRs to the VMM so that it can further
>> preemptively prevent users from forcibly using a non-compatible PVR.
>>
>> Hence IMHO, this patch can be marked for stable tree and potential
>> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
>> tag to this patch
> amit, can you just post this alone as a separate patch, so that we could
> pull it for 7.2 merge?
>
FWIW, b4 am -P1 <mbox> should fetch this patch alone (and not the entire
series), See b4 am --help for more options to select a subset of patches.
regards,
Harsh>
>>> However the new UAPI discussion might still require more discussion with
>>> the community and I don't think it is ready for 7.2 yet ;)
>> Somewhat agree with the above
>>
>>> -ritesh
>>>
>
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Madhavan Srinivasan @ 2026-06-03 4:33 UTC (permalink / raw)
To: Vaibhav Jain, Ritesh Harjani, Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <87se74z4a6.fsf@vajain21.in.ibm.com>
On 6/3/26 9:03 AM, Vaibhav Jain wrote:
> Hi Ritesh, thanks for looking into this patch. My responses to your
> review comments inline below.
>
> Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:
>
>> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>>
>>> So, we would still want to prioritize the whole series
>>> instead of just this one patch.
>>>
>> Patch-1 could go as a bug fix even in 7.1-rc6 (or maybe with 7.2
>> bug fixes). - Maddy?
>>
>> So, you may want to add a fixes tag and maybe even cc stable if you are
>> seeing this issue from older kernels maybe when nestedv2 got introduced?
> This isnt a 'bug fix' per-se but rather strengthening of compat mode
> checks so that any non compatible PVR being used by the VMM can be
> caught early. The hypervisor anyway ultimately prevents non-compatible
> PVRs from being used by the VMM. So there isnt a bug thats being fixed
> in this patch.
>
> The rest of the patch series builds on top of this patch to advertise
> the available compatible PVRs to the VMM so that it can further
> preemptively prevent users from forcibly using a non-compatible PVR.
>
> Hence IMHO, this patch can be marked for stable tree and potential
> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
> tag to this patch
amit, can you just post this alone as a separate patch, so that we could
pull it for 7.2 merge?
>> However the new UAPI discussion might still require more discussion with
>> the community and I don't think it is ready for 7.2 yet ;)
> Somewhat agree with the above
>
>> -ritesh
>>
^ permalink raw reply
* Re: [PATCH v3 4/5] KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM on PowerNV
From: Vaibhav Jain @ 2026-06-03 4:17 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Amit Machhiwal, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <20260522152744.55251-5-amachhiw@linux.ibm.com>
Hi Amit,
Thanks for the patch. My review comments inline:
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> Currently, when booting a compatibility-mode KVM guest (L1) on a PowerNV
> hypervisor (L0), the guest runs with the expected processor
> compatibility level. However, when booting a nested KVM guest (L2)
> inside the L1, QEMU derives the CPU model from the raw host PVR and
> attempts to run the nested guest at that level, instead of honoring the
> compatibility mode of the L1.
>
> Extend host CPU compatibility capability reporting to support nested
> virtualization on PowerNV systems (PAPR nested API v1).
>
> For nested API v2 (PowerVM), compatibility capabilities are obtained
> from the hypervisor via the H_GUEST_GET_CAPABILITIES hcall. This
> information is not available on PowerNV systems.
>
> For nested API v1, derive the compatibility capabilities from the L1
> guest by reading the "cpu-version" property from the device tree, which
> reflects the effective (logical) processor compatibility level. Map this
> value to the corresponding compatibility capability bitmap.
>
> Introduce a helper to translate CPU version values into compatibility
> capability bits and integrate it into kvmppc_get_compat_cpu_caps().
>
> This allows userspace to query host CPU compatibility modes on both
> PowerVM and PowerNV platforms via the KVM_PPC_GET_COMPAT_CAPS ioctl.
>
> Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 37 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 38de7040e2b7..18774c49af85 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6522,15 +6522,50 @@ static bool kvmppc_hash_v3_possible(void)
> return true;
> }
>
> +static int kvmppc_map_compat_capabilities(const __be32 cpu_version,
> + unsigned long *capabilities)
> +{
> + switch (cpu_version) {
> + case PVR_ARCH_31_P11:
> + *capabilities |= H_GUEST_CAP_POWER11;
> + break;
> + case PVR_ARCH_31:
> + *capabilities |= H_GUEST_CAP_POWER10;
> + break;
> + case PVR_ARCH_300:
> + *capabilities |= H_GUEST_CAP_POWER9;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
>
> static int kvmppc_get_compat_cpu_caps(struct kvm_ppc_compat_caps *host_caps)
> {
> + struct device_node *np;
> unsigned long capabilities = 0;
> + const __be32 *prop = NULL;
> long rc = -EINVAL;
> + u32 cpu_version;
>
> if (kvmhv_on_pseries()) {
> - if (kvmhv_is_nestedv2())
> + if (kvmhv_is_nestedv2()) {
> rc = plpar_guest_get_capabilities(0,
> &capabilities);
Need to mask capabilities as mentioned in the review comments for
previous patch. I would suggest creating a helper that performs the
hcall and applies the mask which can then be used at
plpar_guest_get_capabilities() call sites.
> + } else {
> + for_each_node_by_type(np, "cpu") {
> + prop = of_get_property(np, "cpu-version", NULL);
> + if (prop) {
> + cpu_version = be32_to_cpup(prop);
> + break;
> + }
> + }
> + if (!prop)
> + return -EINVAL;
> + rc = kvmppc_map_compat_capabilities(cpu_version,
> + &capabilities);
> + }
> host_caps->compat_capabilities = capabilities;
> }
>
> --
> 2.50.1 (Apple Git-155)
>
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH v3 3/5] KVM: PPC: Book3S HV: Implement compat CPU capability retrieval for KVM on PowerVM
From: Vaibhav Jain @ 2026-06-03 4:01 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Amit Machhiwal, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <20260522152744.55251-4-amachhiw@linux.ibm.com>
Hi Amit,
Thanks for the patch. My review comments inline below:
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> On POWER systems, the host CPU may run in a compatibility mode (e.g., a
> Power11 processor operating in Power10 compatibility mode). In such
> cases, the effective CPU level exposed to guests differs from the
> physical processor generation.
>
> When running nested KVM guests, QEMU derives the host CPU type using
> mfpvr(), which reflects the physical processor version. This can result
> in a mismatch between the CPU model selected by QEMU and the
> compatibility mode enforced by the host, leading to guest boot failures.
>
> For example, booting a nested guest on a Power11 LPAR configured in
> Power10 compatibility mode fails with:
>
> KVM-NESTEDv2: couldn't set guest wide elements
> [..KVM reg dump..]
>
> This occurs because QEMU selects a CPU model corresponding to the
> physical processor (via mfpvr()), while the host operates in a lower
> compatibility mode. As a result, KVM rejects the requested compatibility
> level during guest initialization.
>
> Add support for retrieving host CPU compatibility capabilities for
> nested guests on PowerVM (PAPR nested API v2). The hypervisor provides
> the effective compatibility levels via the H_GUEST_GET_CAPABILITIES
> hcall, which reflects the processor modes negotiated between the Power
> hypervisor (L0) and the host partition (L1).
>
> On pseries systems, obtain the capability bitmap using
> plpar_guest_get_capabilities() and return it via struct
> kvm_ppc_compat_caps. This information is then exposed to userspace
> through the KVM_PPC_GET_COMPAT_CAPS ioctl.
>
> Hook the implementation into the Book3S HV kvmppc_ops so that it can be
> invoked by the generic KVM ioctl handling code.
>
> Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 249d1f2e4e2c..38de7040e2b7 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6522,6 +6522,21 @@ static bool kvmppc_hash_v3_possible(void)
> return true;
> }
>
> +
> +static int kvmppc_get_compat_cpu_caps(struct kvm_ppc_compat_caps *host_caps)
> +{
> + unsigned long capabilities = 0;
> + long rc = -EINVAL;
> +
> + if (kvmhv_on_pseries()) {
> + if (kvmhv_is_nestedv2())
> + rc = plpar_guest_get_capabilities(0,
> &capabilities);
since this value will trikle back to userspace please apply a mask on
the hcall return value so that any reserved and non-PVR related bits
doesnt leak back to userspace.
> + host_caps->compat_capabilities = capabilities;
> + }
> +
> + return rc;
> +}
> +
> static struct kvmppc_ops kvm_ops_hv = {
> .get_sregs = kvm_arch_vcpu_ioctl_get_sregs_hv,
> .set_sregs = kvm_arch_vcpu_ioctl_set_sregs_hv,
> @@ -6564,6 +6579,7 @@ static struct kvmppc_ops kvm_ops_hv = {
> .hash_v3_possible = kvmppc_hash_v3_possible,
> .create_vcpu_debugfs = kvmppc_arch_create_vcpu_debugfs_hv,
> .create_vm_debugfs = kvmppc_arch_create_vm_debugfs_hv,
> + .get_compat_cpu_ver = kvmppc_get_compat_cpu_caps,
> };
>
> static int kvm_init_subcore_bitmap(void)
> --
> 2.50.1 (Apple Git-155)
>
>
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH v3 2/5] KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and wire up ioctl
From: Vaibhav Jain @ 2026-06-03 3:46 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Amit Machhiwal, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <20260522152744.55251-3-amachhiw@linux.ibm.com>
Hi Amit,
Thanks for this patch. Few review comments below:
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> Introduce a new capability and ioctl to expose CPU compatibility modes
> supported by the host processor for nested guests.
>
> On IBM POWER systems, newer processor generations (N) can operate in
> compatibility modes corresponding to earlier generations, like (N-1) and
> (N-2). This is particularly relevant for nested virtualization, where
> nested KVM guests may need to run with a specific processor compatibility
> level.
>
> Introduce KVM_CAP_PPC_COMPAT_CAPS capability and the corresponding
> KVM_PPC_GET_COMPAT_CAPS vm ioctl. The ioctl returns a bitmap describing
> the compatibility modes supported by the host in respective bit numbers,
> allowing userspace (e.g., QEMU) to select an appropriate compatibility
> level when configuring nested KVM guests.
>
> The ioctl handling is added in kvm_arch_vm_ioctl() and retrieves host
> CPU compatibility capabilities via a PowerPC-specific backend
> implementation when available. If the capability is not supported, the
> ioctl returns success with no capabilities set, allowing userspace to
> fall back gracefully.
>
> Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/include/asm/kvm_ppc.h | 1 +
> arch/powerpc/include/uapi/asm/kvm.h | 6 ++++++
> arch/powerpc/kvm/powerpc.c | 21 +++++++++++++++++++++
> include/uapi/linux/kvm.h | 4 ++++
> 4 files changed, 32 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index 0953f2daa466..cadfb839e836 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -319,6 +319,7 @@ struct kvmppc_ops {
> bool (*hash_v3_possible)(void);
> int (*create_vm_debugfs)(struct kvm *kvm);
> int (*create_vcpu_debugfs)(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry);
> + int (*get_compat_cpu_ver)(struct kvm_ppc_compat_caps *host_caps);
> };
>
> extern struct kvmppc_ops *kvmppc_hv_ops;
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 077c5437f521..081d6c7f7f70 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -437,6 +437,12 @@ struct kvm_ppc_cpu_char {
> __u64 behaviour_mask; /* valid bits in behaviour */
> };
>
> +/* For KVM_PPC_GET_COMPAT_CAPS */
> +struct kvm_ppc_compat_caps {
> + __u64 flags; /* Reserved for future use */
Please introduce a size field also for the UAPI so that in this
structure can evolve in future without breaking kernel ABI.
> + __u64 compat_capabilities; /* Capabilities supported by the host */
> +};
> +
> /*
> * Values for character and character_mask.
> * These are identical to the values used by H_GET_CPU_CHARACTERISTICS.
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 00302399fc37..02b834ebd8d3 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -697,6 +697,13 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> }
> }
> break;
> +#if defined(CONFIG_KVM_BOOK3S_HV_POSSIBLE)
> + case KVM_CAP_PPC_COMPAT_CAPS:
> + r = 0;
> + if (kvmhv_on_pseries())
> + r = 1;
> + break;
> +#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
> default:
> r = 0;
> break;
> @@ -2463,6 +2470,20 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> r = kvm->arch.kvm_ops->svm_off(kvm);
> break;
> }
> + case KVM_PPC_GET_COMPAT_CAPS: {
> + struct kvm_ppc_compat_caps host_caps;
> +
> + r = -ENOTTY;
> + memset(&host_caps, 0, sizeof(host_caps));
> + if (!kvm->arch.kvm_ops->get_compat_cpu_ver)
> + goto out;
> +
> + r = kvm->arch.kvm_ops->get_compat_cpu_ver(&host_caps);
> + if (!r && copy_to_user(argp, &host_caps,
> + sizeof(host_caps)))
As mentioned above please introduce a size field in the structure thats
being copied to the userspace and use the size field to copy the
apporiate structure to the userspace. Otherwise a future kernel may
unintentionally overwrite unintended userspace memory if it happens to
be using a larger structure size then what VMM knows about.
> + r = -EFAULT;
> + break;
> + }
> default: {
> struct kvm *kvm = filp->private_data;
> r = kvm->arch.kvm_ops->arch_vm_ioctl(filp, ioctl, arg);
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 6c8afa2047bf..1788a0068662 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_PPC_COMPAT_CAPS 249
>
> struct kvm_irq_routing_irqchip {
> __u32 irqchip;
> @@ -1349,6 +1350,9 @@ struct kvm_s390_keyop {
> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct kvm_device_attr)
> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct kvm_device_attr)
>
> +/* Available with KVM_CAP_PPC_COMPAT_CAPS */
> +#define KVM_PPC_GET_COMPAT_CAPS _IOR(KVMIO, 0xe4, struct
> kvm_ppc_compat_caps)
Minor: you may want to align the name of the newly introduced kvmppc_ops
to KVM CAP you are introducing here.
> +
> /*
> * ioctls for vcpu fds
> */
> --
> 2.50.1 (Apple Git-155)
>
>
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Vaibhav Jain @ 2026-06-03 3:33 UTC (permalink / raw)
To: Ritesh Harjani, Amit Machhiwal
Cc: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan,
Anushree Mathur, Paolo Bonzini, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), Jonathan Corbet, Shuah Khan, kvm,
linux-kernel, linux-doc, lkp
In-Reply-To: <cxyewhx8.ritesh.list@gmail.com>
Hi Ritesh, thanks for looking into this patch. My responses to your
review comments inline below.
Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:
> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>
>> So, we would still want to prioritize the whole series
>> instead of just this one patch.
>>
>
> Patch-1 could go as a bug fix even in 7.1-rc6 (or maybe with 7.2
> bug fixes). - Maddy?
>
> So, you may want to add a fixes tag and maybe even cc stable if you are
> seeing this issue from older kernels maybe when nestedv2 got introduced?
This isnt a 'bug fix' per-se but rather strengthening of compat mode
checks so that any non compatible PVR being used by the VMM can be
caught early. The hypervisor anyway ultimately prevents non-compatible
PVRs from being used by the VMM. So there isnt a bug thats being fixed
in this patch.
The rest of the patch series builds on top of this patch to advertise
the available compatible PVRs to the VMM so that it can further
preemptively prevent users from forcibly using a non-compatible PVR.
Hence IMHO, this patch can be marked for stable tree and potential
candidate for 7.2 merge window. But dont see applicability of a 'fixes'
tag to this patch
> However the new UAPI discussion might still require more discussion with
> the community and I don't think it is ready for 7.2 yet ;)
Somewhat agree with the above
>
> -ritesh
>
--
Cheers
~ Vaibhav
^ permalink raw reply
* [PATCH v6 13/13] selftests/liveupdate: Add stress-files kexec test
From: Pasha Tatashin @ 2026-06-03 3:29 UTC (permalink / raw)
To: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, pasha.tatashin, dmatlack, kexec, pratyush,
skhawaja, graf
In-Reply-To: <20260603032905.344462-1-pasha.tatashin@soleen.com>
Add a new luo_stress_files kexec test that verifies preserving and
retrieving 500 files across a kexec reboot.
Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
tools/testing/selftests/liveupdate/Makefile | 1 +
.../selftests/liveupdate/luo_stress_files.c | 97 +++++++++++++++++++
2 files changed, 98 insertions(+)
create mode 100644 tools/testing/selftests/liveupdate/luo_stress_files.c
diff --git a/tools/testing/selftests/liveupdate/Makefile b/tools/testing/selftests/liveupdate/Makefile
index ed7534468386..30689d22cb02 100644
--- a/tools/testing/selftests/liveupdate/Makefile
+++ b/tools/testing/selftests/liveupdate/Makefile
@@ -7,6 +7,7 @@ TEST_GEN_PROGS += liveupdate
TEST_GEN_PROGS_EXTENDED += luo_kexec_simple
TEST_GEN_PROGS_EXTENDED += luo_multi_session
TEST_GEN_PROGS_EXTENDED += luo_stress_sessions
+TEST_GEN_PROGS_EXTENDED += luo_stress_files
TEST_FILES += do_kexec.sh
diff --git a/tools/testing/selftests/liveupdate/luo_stress_files.c b/tools/testing/selftests/liveupdate/luo_stress_files.c
new file mode 100644
index 000000000000..0cdf9cd4bac7
--- /dev/null
+++ b/tools/testing/selftests/liveupdate/luo_stress_files.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (c) 2026, Google LLC.
+ * Pasha Tatashin <pasha.tatashin@soleen.com>
+ *
+ * Validate that LUO can handle a large number of files per session across
+ * a kexec reboot.
+ */
+
+#include <stdio.h>
+#include <unistd.h>
+#include "luo_test_utils.h"
+
+#define NUM_FILES 500
+#define STATE_SESSION_NAME "kexec_many_files_state"
+#define STATE_MEMFD_TOKEN 9999
+#define TEST_SESSION_NAME "many_files_session"
+
+/* Stage 1: Executed before the kexec reboot. */
+static void run_stage_1(int luo_fd)
+{
+ int session_fd, i;
+
+ ksft_print_msg("[STAGE 1] Creating state file for next stage (2)...\n");
+ create_state_file(luo_fd, STATE_SESSION_NAME, STATE_MEMFD_TOKEN, 2);
+
+ ksft_print_msg("[STAGE 1] Creating test session '%s'...\n", TEST_SESSION_NAME);
+ session_fd = luo_create_session(luo_fd, TEST_SESSION_NAME);
+ if (session_fd < 0)
+ fail_exit("luo_create_session");
+
+ ksft_print_msg("[STAGE 1] Preserving %d files...\n", NUM_FILES);
+ for (i = 0; i < NUM_FILES; i++) {
+ char data[64];
+
+ snprintf(data, sizeof(data), "file-data-%d", i);
+ if (create_and_preserve_memfd(session_fd, i, data) < 0)
+ fail_exit("create_and_preserve_memfd for index %d", i);
+ }
+
+ ksft_print_msg("[STAGE 1] Successfully preserved %d files.\n", NUM_FILES);
+
+ close(luo_fd);
+ daemonize_and_wait();
+}
+
+/* Stage 2: Executed after the kexec reboot. */
+static void run_stage_2(int luo_fd, int state_session_fd)
+{
+ int session_fd;
+ int i, stage;
+
+ ksft_print_msg("[STAGE 2] Starting post-kexec verification...\n");
+
+ restore_and_read_stage(state_session_fd, STATE_MEMFD_TOKEN, &stage);
+ if (stage != 2) {
+ fail_exit("Expected stage 2, but state file contains %d",
+ stage);
+ }
+
+ ksft_print_msg("[STAGE 2] Retrieving test session '%s'...\n", TEST_SESSION_NAME);
+ session_fd = luo_retrieve_session(luo_fd, TEST_SESSION_NAME);
+ if (session_fd < 0)
+ fail_exit("luo_retrieve_session");
+
+ ksft_print_msg("[STAGE 2] Verifying %d files...\n", NUM_FILES);
+ for (i = 0; i < NUM_FILES; i++) {
+ char data[64];
+ int fd;
+
+ snprintf(data, sizeof(data), "file-data-%d", i);
+ fd = restore_and_verify_memfd(session_fd, i, data);
+ if (fd < 0)
+ fail_exit("restore_and_verify_memfd for index %d", i);
+ close(fd);
+ }
+
+ ksft_print_msg("[STAGE 2] Finishing test session...\n");
+ if (luo_session_finish(session_fd) < 0)
+ fail_exit("luo_session_finish for test session");
+ close(session_fd);
+
+ ksft_print_msg("[STAGE 2] Finalizing state session...\n");
+ if (luo_session_finish(state_session_fd) < 0)
+ fail_exit("luo_session_finish for state session");
+ close(state_session_fd);
+
+ ksft_print_msg("\n--- MANY-FILES KEXEC TEST PASSED (%d files) ---\n",
+ NUM_FILES);
+}
+
+int main(int argc, char *argv[])
+{
+ return luo_test(argc, argv, STATE_SESSION_NAME,
+ run_stage_1, run_stage_2);
+}
--
2.53.0
^ permalink raw reply related
* [PATCH v6 12/13] selftests/liveupdate: Add stress-sessions kexec test
From: Pasha Tatashin @ 2026-06-03 3:29 UTC (permalink / raw)
To: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, pasha.tatashin, dmatlack, kexec, pratyush,
skhawaja, graf
In-Reply-To: <20260603032905.344462-1-pasha.tatashin@soleen.com>
Add a new test that creates 2000 LUO sessions before a kexec
reboot and verifies their presence after the reboot. This ensures
that the linked-block serialization mechanism works correctly for
a large number of sessions.
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
tools/testing/selftests/liveupdate/Makefile | 1 +
.../liveupdate/luo_stress_sessions.c | 102 ++++++++++++++++++
2 files changed, 103 insertions(+)
create mode 100644 tools/testing/selftests/liveupdate/luo_stress_sessions.c
diff --git a/tools/testing/selftests/liveupdate/Makefile b/tools/testing/selftests/liveupdate/Makefile
index 080754787ede..ed7534468386 100644
--- a/tools/testing/selftests/liveupdate/Makefile
+++ b/tools/testing/selftests/liveupdate/Makefile
@@ -6,6 +6,7 @@ TEST_GEN_PROGS += liveupdate
TEST_GEN_PROGS_EXTENDED += luo_kexec_simple
TEST_GEN_PROGS_EXTENDED += luo_multi_session
+TEST_GEN_PROGS_EXTENDED += luo_stress_sessions
TEST_FILES += do_kexec.sh
diff --git a/tools/testing/selftests/liveupdate/luo_stress_sessions.c b/tools/testing/selftests/liveupdate/luo_stress_sessions.c
new file mode 100644
index 000000000000..f201b1839d1d
--- /dev/null
+++ b/tools/testing/selftests/liveupdate/luo_stress_sessions.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (c) 2026, Google LLC.
+ * Pasha Tatashin <pasha.tatashin@soleen.com>
+ *
+ * Validate that LUO can handle a large number of sessions across a kexec
+ * reboot.
+ */
+
+#include <stdio.h>
+#include <unistd.h>
+#include "luo_test_utils.h"
+
+#define NUM_SESSIONS 2000
+#define STATE_SESSION_NAME "kexec_many_state"
+#define STATE_MEMFD_TOKEN 999
+
+/* Stage 1: Executed before the kexec reboot. */
+static void run_stage_1(int luo_fd)
+{
+ int ret, i;
+
+ ksft_print_msg("[STAGE 1] Increasing ulimit for open files...\n");
+ ret = luo_ensure_nofile_limit(NUM_SESSIONS);
+ if (ret == -EPERM)
+ ksft_exit_skip("Insufficient privileges to set RLIMIT_NOFILE\n");
+ if (ret < 0)
+ ksft_exit_fail_msg("luo_ensure_nofile_limit failed: %s\n", strerror(-ret));
+
+ ksft_print_msg("[STAGE 1] Creating state file for next stage (2)...\n");
+ create_state_file(luo_fd, STATE_SESSION_NAME, STATE_MEMFD_TOKEN, 2);
+
+ ksft_print_msg("[STAGE 1] Creating %d sessions...\n", NUM_SESSIONS);
+
+ for (i = 0; i < NUM_SESSIONS; i++) {
+ char name[LIVEUPDATE_SESSION_NAME_LENGTH];
+ int s_fd;
+
+ snprintf(name, sizeof(name), "many-test-%d", i);
+ s_fd = luo_create_session(luo_fd, name);
+ if (s_fd < 0) {
+ fail_exit("luo_create_session for '%s' at index %d",
+ name, i);
+ }
+ }
+
+ ksft_print_msg("[STAGE 1] Successfully created %d sessions.\n",
+ NUM_SESSIONS);
+
+ close(luo_fd);
+ daemonize_and_wait();
+}
+
+/* Stage 2: Executed after the kexec reboot. */
+static void run_stage_2(int luo_fd, int state_session_fd)
+{
+ int i, stage;
+
+ ksft_print_msg("[STAGE 2] Starting post-kexec verification...\n");
+
+ restore_and_read_stage(state_session_fd, STATE_MEMFD_TOKEN, &stage);
+ if (stage != 2) {
+ fail_exit("Expected stage 2, but state file contains %d",
+ stage);
+ }
+
+ ksft_print_msg("[STAGE 2] Retrieving and finishing %d sessions...\n",
+ NUM_SESSIONS);
+
+ for (i = 0; i < NUM_SESSIONS; i++) {
+ char name[LIVEUPDATE_SESSION_NAME_LENGTH];
+ int s_fd;
+
+ snprintf(name, sizeof(name), "many-test-%d", i);
+ s_fd = luo_retrieve_session(luo_fd, name);
+ if (s_fd < 0) {
+ fail_exit("luo_retrieve_session for '%s' at index %d",
+ name, i);
+ }
+
+ if (luo_session_finish(s_fd) < 0) {
+ fail_exit("luo_session_finish for '%s' at index %d",
+ name, i);
+ }
+ close(s_fd);
+ }
+
+ ksft_print_msg("[STAGE 2] Finalizing state session...\n");
+ if (luo_session_finish(state_session_fd) < 0)
+ fail_exit("luo_session_finish for state session");
+ close(state_session_fd);
+
+ ksft_print_msg("\n--- MANY-SESSIONS KEXEC TEST PASSED (%d sessions) ---\n",
+ NUM_SESSIONS);
+}
+
+int main(int argc, char *argv[])
+{
+ return luo_test(argc, argv, STATE_SESSION_NAME,
+ run_stage_1, run_stage_2);
+}
--
2.53.0
^ permalink raw reply related
* [PATCH v6 11/13] selftests/liveupdate: Test session and file limit removal
From: Pasha Tatashin @ 2026-06-03 3:29 UTC (permalink / raw)
To: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, pasha.tatashin, dmatlack, kexec, pratyush,
skhawaja, graf
In-Reply-To: <20260603032905.344462-1-pasha.tatashin@soleen.com>
With the removal of static limits on the number of sessions and files per
session, the orchestrator now uses dynamic allocation.
Add new test cases to verify that the system can handle a large number of
sessions and files. These tests ensure that the dynamic block allocation
and reuse logic for session metadata and outgoing files work correctly
beyond the previous static limits.
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
.../testing/selftests/liveupdate/liveupdate.c | 75 +++++++++++++++++++
.../selftests/liveupdate/luo_test_utils.c | 24 ++++++
.../selftests/liveupdate/luo_test_utils.h | 2 +
3 files changed, 101 insertions(+)
diff --git a/tools/testing/selftests/liveupdate/liveupdate.c b/tools/testing/selftests/liveupdate/liveupdate.c
index c7d94b9181e1..502fb3567e38 100644
--- a/tools/testing/selftests/liveupdate/liveupdate.c
+++ b/tools/testing/selftests/liveupdate/liveupdate.c
@@ -26,6 +26,7 @@
#include <linux/liveupdate.h>
+#include "luo_test_utils.h"
#include "../kselftest.h"
#include "../kselftest_harness.h"
@@ -499,4 +500,78 @@ TEST_F(liveupdate_device, get_session_name_max_length)
ASSERT_EQ(close(session_fd), 0);
}
+/*
+ * Test Case: Manage Many Sessions
+ *
+ * Verifies that a large number of sessions can be created and then
+ * destroyed during normal system operation. This specifically tests the
+ * dynamic block allocation and reuse logic for session metadata management
+ * without preserving any files.
+ */
+TEST_F(liveupdate_device, preserve_many_sessions)
+{
+#define MANY_SESSIONS 2000
+ int session_fds[MANY_SESSIONS];
+ int ret, i;
+
+ self->fd1 = open(LIVEUPDATE_DEV, O_RDWR);
+ if (self->fd1 < 0 && errno == ENOENT)
+ SKIP(return, "%s does not exist", LIVEUPDATE_DEV);
+ ASSERT_GE(self->fd1, 0);
+
+ ret = luo_ensure_nofile_limit(MANY_SESSIONS);
+ if (ret == -EPERM)
+ SKIP(return, "Insufficient privileges to set RLIMIT_NOFILE");
+ ASSERT_EQ(ret, 0);
+
+ for (i = 0; i < MANY_SESSIONS; i++) {
+ char name[64];
+
+ snprintf(name, sizeof(name), "many-session-%d", i);
+ session_fds[i] = create_session(self->fd1, name);
+ ASSERT_GE(session_fds[i], 0);
+ }
+
+ for (i = 0; i < MANY_SESSIONS; i++)
+ ASSERT_EQ(close(session_fds[i]), 0);
+}
+
+/*
+ * Test Case: Preserve Many Files
+ *
+ * Verifies that a large number of files can be preserved in a single session
+ * and then destroyed during normal system operation. This tests the dynamic
+ * block allocation and management for outgoing files.
+ */
+TEST_F(liveupdate_device, preserve_many_files)
+{
+#define MANY_FILES 500
+ int mem_fds[MANY_FILES];
+ int session_fd, ret, i;
+
+ self->fd1 = open(LIVEUPDATE_DEV, O_RDWR);
+ if (self->fd1 < 0 && errno == ENOENT)
+ SKIP(return, "%s does not exist", LIVEUPDATE_DEV);
+ ASSERT_GE(self->fd1, 0);
+
+ session_fd = create_session(self->fd1, "many-files-test");
+ ASSERT_GE(session_fd, 0);
+
+ ret = luo_ensure_nofile_limit(MANY_FILES + 10);
+ if (ret == -EPERM)
+ SKIP(return, "Insufficient privileges to set RLIMIT_NOFILE");
+ ASSERT_EQ(ret, 0);
+
+ for (i = 0; i < MANY_FILES; i++) {
+ mem_fds[i] = memfd_create("test-memfd", 0);
+ ASSERT_GE(mem_fds[i], 0);
+ ASSERT_EQ(preserve_fd(session_fd, mem_fds[i], i), 0);
+ }
+
+ for (i = 0; i < MANY_FILES; i++)
+ ASSERT_EQ(close(mem_fds[i]), 0);
+
+ ASSERT_EQ(close(session_fd), 0);
+}
+
TEST_HARNESS_MAIN
diff --git a/tools/testing/selftests/liveupdate/luo_test_utils.c b/tools/testing/selftests/liveupdate/luo_test_utils.c
index 3c8721c505df..333a3530051b 100644
--- a/tools/testing/selftests/liveupdate/luo_test_utils.c
+++ b/tools/testing/selftests/liveupdate/luo_test_utils.c
@@ -17,6 +17,7 @@
#include <sys/syscall.h>
#include <sys/mman.h>
#include <sys/types.h>
+#include <sys/resource.h>
#include <sys/stat.h>
#include <errno.h>
#include <stdarg.h>
@@ -28,6 +29,29 @@ int luo_open_device(void)
return open(LUO_DEVICE, O_RDWR);
}
+int luo_ensure_nofile_limit(long min_limit)
+{
+ struct rlimit hl;
+
+ /* Allow to extra files to be used by test itself */
+ min_limit += 32;
+
+ if (getrlimit(RLIMIT_NOFILE, &hl) < 0)
+ return -errno;
+
+ if (hl.rlim_cur >= min_limit)
+ return 0;
+
+ hl.rlim_cur = min_limit;
+ if (hl.rlim_cur > hl.rlim_max)
+ hl.rlim_max = hl.rlim_cur;
+
+ if (setrlimit(RLIMIT_NOFILE, &hl) < 0)
+ return -errno;
+
+ return 0;
+}
+
int luo_create_session(int luo_fd, const char *name)
{
struct liveupdate_ioctl_create_session arg = { .size = sizeof(arg) };
diff --git a/tools/testing/selftests/liveupdate/luo_test_utils.h b/tools/testing/selftests/liveupdate/luo_test_utils.h
index 90099bf49577..6a0d85386613 100644
--- a/tools/testing/selftests/liveupdate/luo_test_utils.h
+++ b/tools/testing/selftests/liveupdate/luo_test_utils.h
@@ -26,6 +26,8 @@ int luo_create_session(int luo_fd, const char *name);
int luo_retrieve_session(int luo_fd, const char *name);
int luo_session_finish(int session_fd);
+int luo_ensure_nofile_limit(long min_limit);
+
int create_and_preserve_memfd(int session_fd, int token, const char *data);
int restore_and_verify_memfd(int session_fd, int token, const char *expected_data);
--
2.53.0
^ permalink raw reply related
* [PATCH v6 10/13] liveupdate: Remove limit on the number of files per session
From: Pasha Tatashin @ 2026-06-03 3:29 UTC (permalink / raw)
To: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, pasha.tatashin, dmatlack, kexec, pratyush,
skhawaja, graf
In-Reply-To: <20260603032905.344462-1-pasha.tatashin@soleen.com>
To remove the fixed limit on the number of preserved files per session,
transition the file metadata serialization from a single contiguous
memory block to a chain of linked blocks.
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
include/linux/kho/abi/luo.h | 13 +--
kernel/liveupdate/luo_file.c | 138 ++++++++++++++-----------------
kernel/liveupdate/luo_internal.h | 6 +-
3 files changed, 74 insertions(+), 83 deletions(-)
diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h
index 79758d92ed5f..16df550ef143 100644
--- a/include/linux/kho/abi/luo.h
+++ b/include/linux/kho/abi/luo.h
@@ -35,8 +35,8 @@
*
* - struct luo_session_ser:
* Metadata for a single session, including its name and a physical pointer
- * to another preserved memory block containing an array of
- * `struct luo_file_ser` for all files in that session.
+ * to the first `struct kho_block_header_ser` for all files in that session.
+ * Multiple blocks are linked via the `next` field in the header.
*
* - struct luo_file_ser:
* Metadata for a single preserved file. Contains the `compatible` string to
@@ -65,7 +65,7 @@
* The LUO state is registered under this KHO entry name.
*/
#define LUO_KHO_ENTRY_NAME "LUO"
-#define LUO_COMPAT_BASE "luo-v3"
+#define LUO_COMPAT_BASE "luo-v4"
#define LUO_ABI_COMPATIBLE LUO_COMPAT_BASE "-" KHO_BLOCK_ABI_COMPATIBLE
#define LUO_ABI_COMPAT_LEN ALIGN(sizeof(LUO_ABI_COMPATIBLE), 8)
@@ -103,9 +103,10 @@ struct luo_file_ser {
/**
* struct luo_file_set_ser - Represents the serialized metadata for file set
- * @files: The physical address of a contiguous memory block that holds
- * the serialized state of files (array of luo_file_ser) in this file
- * set.
+ * @files: The physical address of the first `struct kho_block_header_ser`.
+ * This structure is the header for a block of memory containing
+ * an array of `struct luo_file_ser` entries. Multiple blocks are
+ * linked via the `next` field in the header.
* @count: The total number of files that were part of this session during
* serialization. Used for iteration and validation during
* restoration.
diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
index 9eec07a9e9fc..c39f96961a85 100644
--- a/kernel/liveupdate/luo_file.c
+++ b/kernel/liveupdate/luo_file.c
@@ -118,11 +118,6 @@ static LIST_HEAD(luo_file_handler_list);
/* Keep track of files being preserved by LUO */
static DEFINE_XARRAY(luo_preserved_files);
-/* 2 4K pages, give space for 128 files per file_set */
-#define LUO_FILE_PGCNT 2ul
-#define LUO_FILE_MAX \
- ((LUO_FILE_PGCNT << PAGE_SHIFT) / sizeof(struct luo_file_ser))
-
/**
* struct luo_file - Represents a single preserved file instance.
* @fh: Pointer to the &struct liveupdate_file_handler that manages
@@ -174,39 +169,6 @@ struct luo_file {
u64 token;
};
-static int luo_alloc_files_mem(struct luo_file_set *file_set)
-{
- size_t size;
- void *mem;
-
- if (file_set->files)
- return 0;
-
- WARN_ON_ONCE(file_set->count);
-
- size = LUO_FILE_PGCNT << PAGE_SHIFT;
- mem = kho_alloc_preserve(size);
- if (IS_ERR(mem))
- return PTR_ERR(mem);
-
- file_set->files = mem;
-
- return 0;
-}
-
-static void luo_free_files_mem(struct luo_file_set *file_set)
-{
- /* If file_set has files, no need to free preservation memory */
- if (file_set->count)
- return;
-
- if (!file_set->files)
- return;
-
- kho_unpreserve_free(file_set->files);
- file_set->files = NULL;
-}
-
static unsigned long luo_get_id(struct liveupdate_file_handler *fh,
struct file *file)
{
@@ -276,16 +238,15 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
if (luo_token_is_used(file_set, token))
return -EEXIST;
- if (file_set->count == LUO_FILE_MAX)
- return -ENOSPC;
+ err = kho_block_set_grow(&file_set->block_set, file_set->count + 1);
+ if (err)
+ return err;
file = fget(fd);
- if (!file)
- return -EBADF;
-
- err = luo_alloc_files_mem(file_set);
- if (err)
- goto err_fput;
+ if (!file) {
+ err = -EBADF;
+ goto err_shrink;
+ }
err = -ENOENT;
down_read(&luo_register_rwlock);
@@ -300,7 +261,7 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
/* err is still -ENOENT if no handler was found */
if (err)
- goto err_free_files_mem;
+ goto err_fput;
err = xa_insert(&luo_preserved_files, luo_get_id(fh, file),
file, GFP_KERNEL);
@@ -343,10 +304,10 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
xa_erase(&luo_preserved_files, luo_get_id(fh, file));
err_module_put:
module_put(fh->ops->owner);
-err_free_files_mem:
- luo_free_files_mem(file_set);
err_fput:
fput(file);
+err_shrink:
+ kho_block_set_shrink(&file_set->block_set, file_set->count);
return err;
}
@@ -392,13 +353,14 @@ void luo_file_unpreserve_files(struct luo_file_set *file_set)
list_del(&luo_file->list);
file_set->count--;
+ kho_block_set_shrink(&file_set->block_set, file_set->count);
fput(luo_file->file);
mutex_destroy(&luo_file->mutex);
kfree(luo_file);
}
- luo_free_files_mem(file_set);
+ kho_block_set_destroy(&file_set->block_set);
}
static int luo_file_freeze_one(struct luo_file_set *file_set,
@@ -454,7 +416,7 @@ static void __luo_file_unfreeze(struct luo_file_set *file_set,
luo_file_unfreeze_one(file_set, luo_file);
}
- memset(file_set->files, 0, LUO_FILE_PGCNT << PAGE_SHIFT);
+ kho_block_set_clear(&file_set->block_set);
}
/**
@@ -493,19 +455,24 @@ static void __luo_file_unfreeze(struct luo_file_set *file_set,
int luo_file_freeze(struct luo_file_set *file_set,
struct luo_file_set_ser *file_set_ser)
{
- struct luo_file_ser *file_ser = file_set->files;
struct luo_file *luo_file;
+ struct kho_block_set_it it;
int err;
- int i;
if (!file_set->count)
return 0;
- if (WARN_ON(!file_ser))
- return -EINVAL;
+ kho_block_set_it_init(&it, &file_set->block_set);
- i = 0;
list_for_each_entry(luo_file, &file_set->files_list, list) {
+ struct luo_file_ser *file_ser = kho_block_set_it_reserve_entry(&it);
+
+ /* This should not fail normally as blocks were pre-allocated */
+ if (WARN_ON_ONCE(!file_ser)) {
+ err = -ENOSPC;
+ goto err_unfreeze;
+ }
+
err = luo_file_freeze_one(file_set, luo_file);
if (err < 0) {
pr_warn("Freeze failed for token[%#0llx] handler[%s] err[%pe]\n",
@@ -514,16 +481,14 @@ int luo_file_freeze(struct luo_file_set *file_set,
goto err_unfreeze;
}
- strscpy(file_ser[i].compatible, luo_file->fh->compatible,
- sizeof(file_ser[i].compatible));
- file_ser[i].data = luo_file->serialized_data;
- file_ser[i].token = luo_file->token;
- i++;
+ strscpy(file_ser->compatible, luo_file->fh->compatible,
+ sizeof(file_ser->compatible));
+ file_ser->data = luo_file->serialized_data;
+ file_ser->token = luo_file->token;
}
file_set_ser->count = file_set->count;
- if (file_set->files)
- file_set_ser->files = virt_to_phys(file_set->files);
+ file_set_ser->files = kho_block_set_head_pa(&file_set->block_set);
return 0;
@@ -741,14 +706,12 @@ int luo_file_finish(struct luo_file_set *file_set)
module_put(luo_file->fh->ops->owner);
list_del(&luo_file->list);
file_set->count--;
+ kho_block_set_shrink(&file_set->block_set, file_set->count);
mutex_destroy(&luo_file->mutex);
kfree(luo_file);
}
- if (file_set->files) {
- kho_restore_free(file_set->files);
- file_set->files = NULL;
- }
+ kho_block_set_destroy(&file_set->block_set);
return 0;
}
@@ -822,16 +785,18 @@ int luo_file_deserialize(struct luo_file_set *file_set,
struct luo_file_set_ser *file_set_ser)
{
struct luo_file_ser *file_ser;
+ struct kho_block_set_it it;
int err;
- u64 i;
if (!file_set_ser->files) {
WARN_ON(file_set_ser->count);
return 0;
}
- file_set->count = file_set_ser->count;
- file_set->files = phys_to_virt(file_set_ser->files);
+ file_set->count = 0;
+ err = kho_block_set_restore(&file_set->block_set, file_set_ser->files);
+ if (err)
+ return err;
/*
* Note on error handling:
@@ -848,25 +813,50 @@ int luo_file_deserialize(struct luo_file_set *file_set,
* userspace to detect the failure and trigger a reboot, which will
* reliably reset devices and reclaim memory.
*/
- file_ser = file_set->files;
- for (i = 0; i < file_set->count; i++) {
- err = luo_file_deserialize_one(file_set, &file_ser[i]);
+ kho_block_set_it_init(&it, &file_set->block_set);
+ while ((file_ser = kho_block_set_it_read_entry(&it))) {
+ err = luo_file_deserialize_one(file_set, file_ser);
if (err)
- return err;
+ goto err_destroy_blocks;
+ file_set->count++;
+ }
+
+ if (file_set->count != file_set_ser->count) {
+ pr_warn("File count mismatch: expected %llu, found %llu\n",
+ file_set_ser->count, file_set->count);
+ err = -EINVAL;
+ goto err_destroy_blocks;
}
return 0;
+
+err_destroy_blocks:
+ while (!list_empty(&file_set->files_list)) {
+ struct luo_file *luo_file;
+
+ luo_file = list_first_entry(&file_set->files_list,
+ struct luo_file, list);
+ list_del(&luo_file->list);
+ module_put(luo_file->fh->ops->owner);
+ mutex_destroy(&luo_file->mutex);
+ kfree(luo_file);
+ }
+ file_set->count = 0;
+ kho_block_set_destroy(&file_set->block_set);
+ return err;
}
void luo_file_set_init(struct luo_file_set *file_set)
{
INIT_LIST_HEAD(&file_set->files_list);
+ kho_block_set_init(&file_set->block_set, sizeof(struct luo_file_ser));
}
void luo_file_set_destroy(struct luo_file_set *file_set)
{
WARN_ON(file_set->count);
WARN_ON(!list_empty(&file_set->files_list));
+ WARN_ON(!kho_block_set_is_empty(&file_set->block_set));
}
/**
diff --git a/kernel/liveupdate/luo_internal.h b/kernel/liveupdate/luo_internal.h
index ee18f9a11b91..64879ffe7378 100644
--- a/kernel/liveupdate/luo_internal.h
+++ b/kernel/liveupdate/luo_internal.h
@@ -10,6 +10,7 @@
#include <linux/liveupdate.h>
#include <linux/uaccess.h>
+#include <linux/kho_block.h>
struct luo_ucmd {
void __user *ubuffer;
@@ -44,14 +45,13 @@ static inline int luo_ucmd_respond(struct luo_ucmd *ucmd,
* struct luo_file_set - A set of files that belong to the same sessions.
* @files_list: An ordered list of files associated with this session, it is
* ordered by preservation time.
- * @files: The physically contiguous memory block that holds the serialized
- * state of files.
+ * @block_set: The set of serialization blocks.
* @count: A counter tracking the number of files currently stored in the
* @files_list for this session.
*/
struct luo_file_set {
struct list_head files_list;
- struct luo_file_ser *files;
+ struct kho_block_set block_set;
u64 count;
};
--
2.53.0
^ permalink raw reply related
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