* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 10:38 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707335CC7035232D44E6ED9F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 01/04/2026 12:31, Guangliu Ding wrote:
>> Either add the patch(es) that use the compatible to this series in v2, or put a
>> comment in the commit message on where we can see the driver changes.
>>
>
> According to discussions with the GPU vendor, this is a hardware limitation
> of Mali-G310 rather than a hardware bug, and it has been addressed in newer
> Mali GPU families.
>
> In addition, ipa_counters are not enabled in the current Panthor driver. We observed
> this issue with the private Mali DDK where ipa_counters were enabled.
> Therefore, keeping the compatible string is necessary to allow for future divergence.
No one discusses here whether you need separate compatible string.
writing bindings and all my talks are (e.g. DTS 101) are clearly
expecting you.
We discuss only the lack of compatibility in terms of DT, how DT sees
compatible devices.
And lack of driver code is clear indication that devices are compatible
in terms how DT understands it. Feel encouraged to bring actual
arguments in commit msgs in the future.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 16/16] KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtime
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
set_id_regs creates a GIC3 guest when possible, and then proceeds
to write the ID registers as if they were not affected by the presence
of a GIC. As it turns out, ID_AA64PFR1_EL1 is the proof of the
contrary.
KVM now makes a point in exposing the GIC support to the guest,
no matter what userspace says (userspace such as QEMU is known to
write silly things at times).
Accommodate for this level of nonsense by teaching set_id_regs about
fields that are mutable, and only compare registers that have been
re-sanitised first.
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
.../testing/selftests/kvm/arm64/set_id_regs.c | 52 ++++++++++++++++---
1 file changed, 45 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/kvm/arm64/set_id_regs.c b/tools/testing/selftests/kvm/arm64/set_id_regs.c
index 73de5be58bab0..7899d557c70b6 100644
--- a/tools/testing/selftests/kvm/arm64/set_id_regs.c
+++ b/tools/testing/selftests/kvm/arm64/set_id_regs.c
@@ -37,6 +37,9 @@ struct reg_ftr_bits {
* For FTR_LOWER_SAFE, safe_val is used as the minimal safe value.
*/
int64_t safe_val;
+
+ /* Allowed to be changed by the host after run */
+ bool mutable;
};
struct test_feature_reg {
@@ -44,7 +47,7 @@ struct test_feature_reg {
const struct reg_ftr_bits *ftr_bits;
};
-#define __REG_FTR_BITS(NAME, SIGNED, TYPE, SHIFT, MASK, SAFE_VAL) \
+#define __REG_FTR_BITS(NAME, SIGNED, TYPE, SHIFT, MASK, SAFE_VAL, MUT) \
{ \
.name = #NAME, \
.sign = SIGNED, \
@@ -52,15 +55,20 @@ struct test_feature_reg {
.shift = SHIFT, \
.mask = MASK, \
.safe_val = SAFE_VAL, \
+ .mutable = MUT, \
}
#define REG_FTR_BITS(type, reg, field, safe_val) \
__REG_FTR_BITS(reg##_##field, FTR_UNSIGNED, type, reg##_##field##_SHIFT, \
- reg##_##field##_MASK, safe_val)
+ reg##_##field##_MASK, safe_val, false)
+
+#define REG_FTR_BITS_MUTABLE(type, reg, field, safe_val) \
+ __REG_FTR_BITS(reg##_##field, FTR_UNSIGNED, type, reg##_##field##_SHIFT, \
+ reg##_##field##_MASK, safe_val, true)
#define S_REG_FTR_BITS(type, reg, field, safe_val) \
__REG_FTR_BITS(reg##_##field, FTR_SIGNED, type, reg##_##field##_SHIFT, \
- reg##_##field##_MASK, safe_val)
+ reg##_##field##_MASK, safe_val, false)
#define REG_FTR_END \
{ \
@@ -134,7 +142,8 @@ static const struct reg_ftr_bits ftr_id_aa64pfr0_el1[] = {
REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64PFR0_EL1, CSV2, 0),
REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64PFR0_EL1, DIT, 0),
REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64PFR0_EL1, SEL2, 0),
- REG_FTR_BITS(FTR_EXACT, ID_AA64PFR0_EL1, GIC, 0),
+ /* GICv3 support will be forced at run time if available */
+ REG_FTR_BITS_MUTABLE(FTR_EXACT, ID_AA64PFR0_EL1, GIC, 0),
REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64PFR0_EL1, EL3, 1),
REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64PFR0_EL1, EL2, 1),
REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64PFR0_EL1, EL1, 1),
@@ -634,12 +643,38 @@ static void test_user_set_mte_reg(struct kvm_vcpu *vcpu)
ksft_test_result_pass("ID_AA64PFR1_EL1.MTE_frac no longer 0xF\n");
}
+static uint64_t reset_mutable_bits(uint32_t id, uint64_t val)
+{
+ struct test_feature_reg *reg = NULL;
+
+ for (int i = 0; i < ARRAY_SIZE(test_regs); i++) {
+ if (test_regs[i].reg == id) {
+ reg = &test_regs[i];
+ break;
+ }
+ }
+
+ if (!reg)
+ return val;
+
+ for (const struct reg_ftr_bits *bits = reg->ftr_bits; bits->type != FTR_END; bits++) {
+ if (bits->mutable) {
+ val &= ~bits->mask;
+ val |= bits->safe_val << bits->shift;
+ }
+ }
+
+ return val;
+}
+
static void test_guest_reg_read(struct kvm_vcpu *vcpu)
{
bool done = false;
struct ucall uc;
while (!done) {
+ uint64_t val;
+
vcpu_run(vcpu);
switch (get_ucall(vcpu, &uc)) {
@@ -647,9 +682,11 @@ static void test_guest_reg_read(struct kvm_vcpu *vcpu)
REPORT_GUEST_ASSERT(uc);
break;
case UCALL_SYNC:
+ val = test_reg_vals[encoding_to_range_idx(uc.args[2])];
+ val = reset_mutable_bits(uc.args[2], val);
+
/* Make sure the written values are seen by guest */
- TEST_ASSERT_EQ(test_reg_vals[encoding_to_range_idx(uc.args[2])],
- uc.args[3]);
+ TEST_ASSERT_EQ(val, reset_mutable_bits(uc.args[2], uc.args[3]));
break;
case UCALL_DONE:
done = true;
@@ -740,7 +777,8 @@ static void test_assert_id_reg_unchanged(struct kvm_vcpu *vcpu, uint32_t encodin
uint64_t observed;
observed = vcpu_get_reg(vcpu, KVM_ARM64_SYS_REG(encoding));
- TEST_ASSERT_EQ(test_reg_vals[idx], observed);
+ TEST_ASSERT_EQ(reset_mutable_bits(encoding, test_reg_vals[idx]),
+ reset_mutable_bits(encoding, observed));
}
static void test_reset_preserves_id_regs(struct kvm_vcpu *vcpu)
--
2.47.3
^ permalink raw reply related
* [PATCH v2 10/16] KVM: arm64: vgic-v5: Correctly set dist->ready once initialised
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
kvm_vgic_map_resources() targetting a v5 model results in vgic->dist_ready
never being set. This doesn't result in anything really bad, only
some more heavy locking as we go and re-init something for no good reason.
Rejig the code to correctly set the ready flag in all non-failing
cases.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: f4d37c7c35769 ("KVM: arm64: gic-v5: Create and initialise vgic_v5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-init.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index fd872079f2a24..ecb0aea180327 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -657,16 +657,20 @@ int kvm_vgic_map_resources(struct kvm *kvm)
needs_dist = false;
}
- if (ret || !needs_dist)
+ if (ret)
goto out;
- dist_base = dist->vgic_dist_base;
- mutex_unlock(&kvm->arch.config_lock);
+ if (needs_dist) {
+ dist_base = dist->vgic_dist_base;
+ mutex_unlock(&kvm->arch.config_lock);
- ret = vgic_register_dist_iodev(kvm, dist_base, type);
- if (ret) {
- kvm_err("Unable to register VGIC dist MMIO regions\n");
- goto out_slots;
+ ret = vgic_register_dist_iodev(kvm, dist_base, type);
+ if (ret) {
+ kvm_err("Unable to register VGIC dist MMIO regions\n");
+ goto out_slots;
+ }
+ } else {
+ mutex_unlock(&kvm->arch.config_lock);
}
smp_store_release(&dist->ready, true);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 08/16] KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behaviours
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
Passing a u64 to __builtin_ctz() is odd, and requires some digging to
figure out why this construct is indeed safe as long as the HW is
correct.
But it is much easier to make it clear to the compiler by casting
the u64 into an intermediate u32, and be done with the UD.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-v5.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 422741c86c6a8..0f269321ece4b 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -212,7 +212,7 @@ int vgic_v5_finalize_ppi_state(struct kvm *kvm)
static u32 vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
{
struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
- u32 highest_ap, priority_mask;
+ u32 highest_ap, priority_mask, apr;
/*
* If the guest's CPU has not opted to receive interrupts, then the
@@ -227,7 +227,8 @@ static u32 vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
* priority. Explicitly use the 32-bit version here as we have 32
* priorities. 32 then means that there are no active priorities.
*/
- highest_ap = cpu_if->vgic_apr ? __builtin_ctz(cpu_if->vgic_apr) : 32;
+ apr = cpu_if->vgic_apr;
+ highest_ap = apr ? __builtin_ctz(apr) : 32;
/*
* An interrupt is of sufficient priority if it is equal to or
--
2.47.3
^ permalink raw reply related
* [PATCH v2 05/16] KVM: arm64: Account for RESx bits in __compute_fgt()
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown, stable
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
When computing Fine Grained Traps, it is preferable to account for
the reserved bits. The HW will most probably ignore them, unless the
bits have been repurposed to do something else.
Use caution, and fold our view of the reserved bits in,
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: c259d763e6b09 ("KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
---
arch/arm64/kvm/config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
index e14685343191b..f35b8dddd7c1f 100644
--- a/arch/arm64/kvm/config.c
+++ b/arch/arm64/kvm/config.c
@@ -1663,8 +1663,8 @@ static __always_inline void __compute_fgt(struct kvm_vcpu *vcpu, enum vcpu_sysre
clear |= ~nested & m->nmask;
}
- val |= set;
- val &= ~clear;
+ val |= set | m->res1;
+ val &= ~(clear | m->res0);
*vcpu_fgt(vcpu, reg) = val;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 13/16] KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid()
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
Userspace can set the timer PPI numbers way before a GIC has been
created, leading to odd behaviours on GICv5 as we'd accept non
architectural PPI numbers.
Move the v5 check into timer_irqs_are_valid(), which aligns the
behaviour with the pre-v5 GICs, and is also guaranteed to run
only once a GIC has been configured.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 6608c47d1f628..cbea4d9ee9552 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -1543,6 +1543,10 @@ static bool timer_irqs_are_valid(struct kvm_vcpu *vcpu)
if (kvm_vgic_set_owner(vcpu, irq, ctx))
break;
+ /* With GICv5, the default PPI is what you get -- nothing else */
+ if (vgic_is_v5(vcpu->kvm) && irq != get_vgic_ppi(vcpu->kvm, default_ppi[i]))
+ break;
+
/*
* We know by construction that we only have PPIs, so all values
* are less than 32 for non-GICv5 VGICs. On GICv5, they are
@@ -1678,13 +1682,6 @@ int kvm_arm_timer_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
return -ENXIO;
}
- /*
- * The PPIs for the Arch Timers are architecturally defined for
- * GICv5. Reject anything that changes them from the specified value.
- */
- if (vgic_is_v5(vcpu->kvm) && vcpu->kvm->arch.timer_data.ppi[idx] != irq)
- return -EINVAL;
-
/*
* We cannot validate the IRQ unicity before we run, so take it at
* face value. The verdict will be given on first vcpu run, for each
--
2.47.3
^ permalink raw reply related
* [PATCH v2 09/16] KVM: arm64: vgic-v5: Make the effective priority mask a strict limit
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
The way the effective priority mask is compared to the priority of
an interrupt to decide whether to wake-up or not, is slightly odd,
and breaks at the limits.
This could result in spurious wake-ups that are undesirable.
Make the computed priority mask comparison a strict inequality, so
that interrupts that have the same priority as the mask are not
signalled.
Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-v5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 0f269321ece4b..31040cfb61fc7 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -367,7 +367,7 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu *vcpu)
scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
has_pending = (irq->enabled && irq_is_pending(irq) &&
- irq->priority <= priority_mask);
+ irq->priority < priority_mask);
vgic_put_irq(vcpu->kvm, irq);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 14/16] KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
While we now compute ID_AA64PFR2_EL1 to a glorious 0, we never use
that data and instead return the 0 that corresponds to an allocated
idreg. Not a big deal, but we might as well be consistent.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 5aefaf11f9af5 ("KVM: arm64: gic: Hide GICv5 for protected guests")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
index b40fd01ebf329..be6f420388a14 100644
--- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
+++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
@@ -439,7 +439,7 @@ static const struct sys_reg_desc pvm_sys_reg_descs[] = {
/* CRm=4 */
AARCH64(SYS_ID_AA64PFR0_EL1),
AARCH64(SYS_ID_AA64PFR1_EL1),
- ID_UNALLOCATED(4,2),
+ AARCH64(SYS_ID_AA64PFR2_EL1),
ID_UNALLOCATED(4,3),
AARCH64(SYS_ID_AA64ZFR0_EL1),
ID_UNALLOCATED(4,5),
--
2.47.3
^ permalink raw reply related
* [PATCH v2 15/16] KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supported
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
Although the AArch32 ID regs are architecturally UNKNOWN when AArch32
isn't supported at any EL, KVM makes a point in making them RAZ.
Therefore, advertising GICv3 in ID_PFR1_EL1 must be gated on AArch32
being supported at least at EL0.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE")
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index ecb0aea180327..5c684ecf79e66 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -700,7 +700,8 @@ void kvm_vgic_finalize_idregs(struct kvm *kvm)
break;
case KVM_DEV_TYPE_ARM_VGIC_V3:
aa64pfr0 |= SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, GIC, IMP);
- pfr1 |= SYS_FIELD_PREP_ENUM(ID_PFR1_EL1, GIC, GICv3);
+ if (kvm_supports_32bit_el0())
+ pfr1 |= SYS_FIELD_PREP_ENUM(ID_PFR1_EL1, GIC, GICv3);
break;
case KVM_DEV_TYPE_ARM_VGIC_V5:
aa64pfr2 |= SYS_FIELD_PREP_ENUM(ID_AA64PFR2_EL1, GCIE, IMP);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 12/16] KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
The vgic-v5 code added some evaluations of the timers in a helper funtion
(kvm_cpu_has_pending_timer()) that is called to determine whether
the vcpu can wake-up.
But looking at the timer there is wrong:
- we want to see timers that are signalling an interrupt to the
vcpu, and not just that have a pending interrupt
- we already have kvm_arch_vcpu_runnable() that evaluates the
state of interrupts
- kvm_cpu_has_pending_timer() really is about WFIT, as the timeout
does not generate an interrupt, and is therefore distinct from
the point above
As a consequence, revert these changes and teach vgic_v5_has_pending_ppi()
about checking for pending HW interrupts instead.
Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 6 +-----
arch/arm64/kvm/vgic/vgic-v5.c | 4 ++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 37279f8748695..6608c47d1f628 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -402,11 +402,7 @@ static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx)
int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
{
- struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
- struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
-
- return kvm_timer_should_fire(vtimer) || kvm_timer_should_fire(ptimer) ||
- (vcpu_has_wfit_active(vcpu) && wfit_delay_ns(vcpu) == 0);
+ return vcpu_has_wfit_active(vcpu) && wfit_delay_ns(vcpu) == 0;
}
/*
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 31040cfb61fc7..8680a8354db9d 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -366,8 +366,8 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu *vcpu)
irq = vgic_get_vcpu_irq(vcpu, intid);
scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
- has_pending = (irq->enabled && irq_is_pending(irq) &&
- irq->priority < priority_mask);
+ if (irq->enabled && irq->priority < priority_mask)
+ has_pending = irq->hw ? vgic_get_phys_line_level(irq) : irq_is_pending(irq);
vgic_put_irq(vcpu->kvm, irq);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 04/16] KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1
From: Marc Zyngier @ 2026-04-01 10:35 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
The writeable mask for fields in ID_AA64PFR2_EL1 has been accidentally
inverted, which isn't a very good idea.
Restore the expected polarity.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/sys_regs.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 18e2d2fccedb8..6a96cb7ba9a3c 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -3304,10 +3304,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
ID_AA64PFR1_EL1_MPAM_frac |
ID_AA64PFR1_EL1_MTE)),
ID_FILTERED(ID_AA64PFR2_EL1, id_aa64pfr2_el1,
- ~(ID_AA64PFR2_EL1_FPMR |
- ID_AA64PFR2_EL1_MTEFAR |
- ID_AA64PFR2_EL1_MTESTOREONLY |
- ID_AA64PFR2_EL1_GCIE)),
+ (ID_AA64PFR2_EL1_FPMR |
+ ID_AA64PFR2_EL1_MTEFAR |
+ ID_AA64PFR2_EL1_MTESTOREONLY |
+ ID_AA64PFR2_EL1_GCIE)),
ID_UNALLOCATED(4,3),
ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),
ID_HIDDEN(ID_AA64SMFR0_EL1),
--
2.47.3
^ permalink raw reply related
* [PATCH v2 11/16] KVM: arm64: Kill arch_timer_context::direct field
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
The newly introduced arch_timer_context::direct field is a bit pointless,
as it is always set on timers that are... err... direct, while
we already have a way to get to that by doing a get_map() operation.
Additionally, this field is:
- only set when get_map() is called
- never cleared
and the single point where it is actually checked doesn't call get_map()
at all.
At this stage, it is probably better to just kill it, and rely on
get_map() to give us the correct information.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 15 +++++++++------
include/kvm/arm_arch_timer.h | 3 ---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 67b989671b410..37279f8748695 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -183,10 +183,6 @@ void get_timer_map(struct kvm_vcpu *vcpu, struct timer_map *map)
map->emul_ptimer = vcpu_ptimer(vcpu);
}
- map->direct_vtimer->direct = true;
- if (map->direct_ptimer)
- map->direct_ptimer->direct = true;
-
trace_kvm_get_timer_map(vcpu->vcpu_id, map);
}
@@ -462,8 +458,15 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
return;
/* Skip injecting on GICv5 for directly injected (DVI'd) timers */
- if (vgic_is_v5(vcpu->kvm) && timer_ctx->direct)
- return;
+ if (vgic_is_v5(vcpu->kvm)) {
+ struct timer_map map;
+
+ get_timer_map(vcpu, &map);
+
+ if (map.direct_ptimer == timer_ctx ||
+ map.direct_vtimer == timer_ctx)
+ return;
+ }
kvm_vgic_inject_irq(vcpu->kvm, vcpu,
timer_irq(timer_ctx),
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index a7754e0a2ef41..bf8cc9589bd09 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -76,9 +76,6 @@ struct arch_timer_context {
/* Duplicated state from arch_timer.c for convenience */
u32 host_timer_irq;
-
- /* Is this a direct timer? */
- bool direct;
};
struct timer_map {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 07/16] KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
While it is perfectly correct to leave the pending state of a level
interrupt as is when queuing it (it is, after all, only driven by
the line), edge pending state must be transfered, as nothing will
lower it.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 4d591252bacb2 ("KVM: arm64: gic-v5: Implement PPI interrupt injection")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-v5.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 119d7d01d0e77..422741c86c6a8 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -445,8 +445,11 @@ void vgic_v5_flush_ppi_state(struct kvm_vcpu *vcpu)
irq = vgic_get_vcpu_irq(vcpu, intid);
- scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
+ scoped_guard(raw_spinlock_irqsave, &irq->irq_lock) {
__assign_bit(i, pendr, irq_is_pending(irq));
+ if (irq->config == VGIC_CONFIG_EDGE)
+ irq->pending_latch = false;
+ }
vgic_put_irq(vcpu->kvm, irq);
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 01/16] KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time
From: Marc Zyngier @ 2026-04-01 10:35 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
Although we are OK with rewriting idregs at finalize time, resetting
the guest's cpuif (GICv3) or redistributor (GICv3) addresses once
we start running the guest is a pretty bad idea.
Move back this initialisation to vgic creation time.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE")
Link: https://patch.msgid.link/20260323174713.3183111-1-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-init.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 47169604100f2..fd872079f2a24 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -147,6 +147,15 @@ int kvm_vgic_create(struct kvm *kvm, u32 type)
kvm->arch.vgic.implementation_rev = KVM_VGIC_IMP_REV_LATEST;
kvm->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
+ switch (type) {
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
+ kvm->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
+ INIT_LIST_HEAD(&kvm->arch.vgic.rd_regions);
+ break;
+ }
+
/*
* We've now created the GIC. Update the system register state
* to accurately reflect what we've created.
@@ -684,10 +693,8 @@ void kvm_vgic_finalize_idregs(struct kvm *kvm)
switch (type) {
case KVM_DEV_TYPE_ARM_VGIC_V2:
- kvm->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
break;
case KVM_DEV_TYPE_ARM_VGIC_V3:
- INIT_LIST_HEAD(&kvm->arch.vgic.rd_regions);
aa64pfr0 |= SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, GIC, IMP);
pfr1 |= SYS_FIELD_PREP_ENUM(ID_PFR1_EL1, GIC, GICv3);
break;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 02/16] KVM: arm64: Don't skip per-vcpu NV initialisation
From: Marc Zyngier @ 2026-04-01 10:35 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
Some GICv5-related rework have resulted in the NV sanitisation of
registers being skipped for secondary vcpus, which is a pretty bad
idea.
Hoist the NV init early so that it is always executed.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: cbd8c958be54a ("KVM: arm64: Return early from kvm_finalize_sys_regs() if guest has run")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/sys_regs.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e1001544d4f40..18e2d2fccedb8 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -5772,6 +5772,12 @@ int kvm_finalize_sys_regs(struct kvm_vcpu *vcpu)
guard(mutex)(&kvm->arch.config_lock);
+ if (vcpu_has_nv(vcpu)) {
+ int ret = kvm_init_nv_sysregs(vcpu);
+ if (ret)
+ return ret;
+ }
+
if (kvm_vm_has_ran_once(kvm))
return 0;
@@ -5820,12 +5826,6 @@ int kvm_finalize_sys_regs(struct kvm_vcpu *vcpu)
kvm_vgic_finalize_idregs(kvm);
}
- if (vcpu_has_nv(vcpu)) {
- int ret = kvm_init_nv_sysregs(vcpu);
- if (ret)
- return ret;
- }
-
return 0;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 06/16] KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIs
From: Marc Zyngier @ 2026-04-01 10:36 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
Finalizing the PPI state is done without holding any lock, which
means that two vcpus can race against each other and have one zeroing
the state while another one is setting it, or even maybe using it.
Fixing this is done by:
- holding the config lock while performing the initialisation
- checking if SW_PPI has already been advertised, meaning that
we have already completed the initialisation once
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 8f1fbe2fd2792 ("KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-v5.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 2b6cd5c3f9c2f..119d7d01d0e77 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -172,6 +172,16 @@ int vgic_v5_finalize_ppi_state(struct kvm *kvm)
if (!vgic_is_v5(kvm))
return 0;
+ guard(mutex)(&kvm->arch.config_lock);
+
+ /*
+ * If SW_PPI has been advertised, then we know we already
+ * initialised the whole thing, and we can return early. Yes,
+ * this is pretty hackish as far as state tracking goes...
+ */
+ if (test_bit(GICV5_ARCH_PPI_SW_PPI, kvm->arch.vgic.gicv5_vm.vgic_ppi_mask))
+ return 0;
+
/* The PPI state for all VCPUs should be the same. Pick the first. */
vcpu0 = kvm_get_vcpu(kvm, 0);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 00/16] KVM: arm64: First batch of vgic-v5 related fixes
From: Marc Zyngier @ 2026-04-01 10:35 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
This is the second revision of this series attempting to fix a number
of issues reported on the vgic-v5 PPI series.
* From v1 [1]:
- Partially reverted the effective priority mask fix, as Sascha
pointed out the crucial difference in the way GICv5 manages the
PCR compared to GICv[234]'s PMR.
- Added a fix for dealing with the pending HW-backed PPIs.
- Added a workaround for the set_id_regs selftest, already posted
separately, but included here for completeness (and ease of
merging).
Patches on top of my kvm-arm64/vgic-v5-ppi branch.
[1] https://lore.kernel.org/r/20260326153530.3981879-1-maz@kernel.org
Marc Zyngier (16):
KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time
KVM: arm64: Don't skip per-vcpu NV initialisation
arm64: Fix field references for ICH_PPI_DVIR[01]_EL2
KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1
KVM: arm64: Account for RESx bits in __compute_fgt()
KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIs
KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2
KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined
behaviours
KVM: arm64: vgic-v5: Make the effective priority mask a strict limit
KVM: arm64: vgic-v5: Correctly set dist->ready once initialised
KVM: arm64: Kill arch_timer_context::direct field
KVM: arm64: Remove evaluation of timer state in
kvm_cpu_has_pending_timer()
KVM: arm64: Move GICv5 timer PPI validation into
timer_irqs_are_valid()
KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling
KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't
supported
KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtime
arch/arm64/kvm/arch_timer.c | 32 +++++-------
arch/arm64/kvm/config.c | 4 +-
arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +-
arch/arm64/kvm/sys_regs.c | 20 +++----
arch/arm64/kvm/vgic/vgic-init.c | 32 ++++++++----
arch/arm64/kvm/vgic/vgic-v5.c | 24 +++++++--
arch/arm64/tools/sysreg | 4 +-
include/kvm/arm_arch_timer.h | 3 --
.../testing/selftests/kvm/arm64/set_id_regs.c | 52 ++++++++++++++++---
9 files changed, 115 insertions(+), 58 deletions(-)
base-commit: ce29261ec6482de54320c03398eb30e9615aee40
--
2.47.3
^ permalink raw reply
* [PATCH v2 03/16] arm64: Fix field references for ICH_PPI_DVIR[01]_EL2
From: Marc Zyngier @ 2026-04-01 10:35 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
The ICH_PPI_DVIR[01]_EL2 registers should refer to the ICH_PPI_DVIRx_EL2
fields, instead of ICH_PPI_DVIx_EL2.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 2808a8337078f ("arm64/sysreg: Add remaining GICv5 ICC_ & ICH_ sysregs for KVM support")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/tools/sysreg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 51dcca5b2fa6e..3b57cb692c5be 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -4888,11 +4888,11 @@ Field 0 DVI0
EndSysregFields
Sysreg ICH_PPI_DVIR0_EL2 3 4 12 10 0
-Fields ICH_PPI_DVIx_EL2
+Fields ICH_PPI_DVIRx_EL2
EndSysreg
Sysreg ICH_PPI_DVIR1_EL2 3 4 12 10 1
-Fields ICH_PPI_DVIx_EL2
+Fields ICH_PPI_DVIRx_EL2
EndSysreg
SysregFields ICH_PPI_ENABLERx_EL2
--
2.47.3
^ permalink raw reply related
* RE: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 10:31 UTC (permalink / raw)
To: Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <aczv0R0aQRmHKdvt@e142607>
Hi Liviu
> On Wed, Apr 01, 2026 at 09:43:12AM +0000, Guangliu Ding wrote:
> > Hi Daniel
> >
> > > On 4/1/26 11:48, Guangliu Ding wrote:
> > > > [You don't often get email from guangliu.ding@nxp.com. Learn why
> > > > this is important at https://aka.ms/LearnAboutSenderIdentification
> > > > ]
> > > >
> > > > Hi Liviu
> > > >
> > > > Thanks for your review. Please refer to my comments below:
> > > >
> > > >> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> > > >>> Add compatible string of Mali G310 GPU on i.MX952 board.
> > > >>>
> > > >>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > > >>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > > >>> ---
> > > >>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > > >>> | 1
> > > >>> +
> > > >>> 1 file changed, 1 insertion(+)
> > > >>>
> > > >>> diff --git
> > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yam
> > > >>> l
> > > >> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > > >>> index 8eccd4338a2b..6a10843a26e2 100644
> > > >>> ---
> > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yam
> > > >>> l
> > > >>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf
> > > >>> +++ .yam
> > > >>> +++ l
> > > >>> @@ -20,6 +20,7 @@ properties:
> > > >>> - enum:
> > > >>> - mediatek,mt8196-mali
> > > >>> - nxp,imx95-mali # G310
> > > >>> + - nxp,imx952-mali # G310
> > > >> Can you explain why this is needed? Can it not be covered by the
> > > >> existing compatible?
> > > > There are functional differences in GPU module (GPUMIX) between
> > > > i.MX95 and i.MX952. So they cannot be fully covered by a single existing
> compatible.
> > > > On i.MX952, The GPU clock is controlled by hardware GPU auto
> > > > clock-gating mechanism, while the GPU clock is managed explicitly
> > > > by the
> > > driver on i.MX95.
> > > > Because of these behavioral differences, separate compatible
> > > > strings "nxp,imx95-mali" and "nxp,imx952-mali" are needed to allow
> > > > the driver to handle the two variants independently and to keep
> > > > room for future
> > > divergence.
> > >
> > >
> > > This information should be added in the commit message explaining
> > > why
> > >
> > > the change is needed.
> > >
> > >
> > > But then where is the driver code taking care of these diferences?
> > >
> >
> > Yes. Currently the driver does not require "nxp,imx952-mali" string.
> > However, when GPU ipa_counters are enabled to calculate the GPU
> > busy_time/idle_time for GPU DVFS feature, they will conflict with the
> > hardware GPU auto clock‑gating mechanism, causing GPU clock to remain
> always on.
> > In such cases, ipa_counters need to be disabled so that the GPU auto
> > clock‑gating mechanism can operate normally, using "nxp,imx952-mali"
> string.
>
> OK, I understand that you're following guidance from some other senior
> people on how to upstream patches so you've tried to create the smallest
> patchset to ensure that it gets reviewed and accepted, but in this case we need
> to see the other patches as well to decide if your approach is the right one and
> we do need a separate compatible string.
>
> If enabling GPU ipa_counters causes the clocks to get stuck active, that feels
> like a hardware bug, so figuring out how to handle that is more important than
> adding a compatible string.
>
> Either add the patch(es) that use the compatible to this series in v2, or put a
> comment in the commit message on where we can see the driver changes.
>
According to discussions with the GPU vendor, this is a hardware limitation
of Mali-G310 rather than a hardware bug, and it has been addressed in newer
Mali GPU families.
In addition, ipa_counters are not enabled in the current Panthor driver. We observed
this issue with the private Mali DDK where ipa_counters were enabled.
Therefore, keeping the compatible string is necessary to allow for future divergence.
> Best regards,
> Liviu
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH v2 1/2] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Geert Uytterhoeven @ 2026-04-01 10:28 UTC (permalink / raw)
To: Alex Bereza
Cc: Vinod Koul, Frank Li, Michal Simek, Ulf Hansson, Arnd Bergmann,
Tony Lindgren, Kedareswara rao Appana, dmaengine,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v2-1-68a265e3770f@bereza.email>
Hi Alex,
Thanks for your patch!
On Wed, 1 Apr 2026 at 11:58, Alex Bereza <alex@bereza.email> wrote:
> Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a
> condition that is never fulfilled, the CPU busy-waits for prolonged time
> and the timeout triggers only with a massive delay causing a CPU stall.
>
> This happens due to a huge underestimation of wall clock time in
> poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use
> timekeeping in read_poll_timeout_atomic()") changed the behavior to no
> longer use ktime_get at the expense of underestimation of wall clock
> time which appears to be very large for delay_us=0. Instead of timing
> out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout
> takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for
> loop in poll_timeout_us_atomic takes) which is in the range of several
> minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero
> value for delay_us. Use delay_us=10 to keep the delay in the hot path of
> starting DMA transfers minimal but still avoid CPU stalls in case of
> unexpected hardware failures.
>
> One-off measurement with delay_us=0 causes the cpu to busy wait around 7
> minutes in the timeout case. After applying this patch with delay_us=10
> the measured timeout was 1053428 microseconds which is roughly
> equivalent to the expected 1000000 microseconds specified in
> XILINX_DMA_LOOP_COUNT.
>
> Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.
>
> Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's")
> Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()")
>
Please no blank line between tags.
> Signed-off-by: Alex Bereza <alex@bereza.email>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] iommu/rockchip: fix page table allocation flags for v2 IOMMU
From: Simon Xue @ 2026-04-01 10:22 UTC (permalink / raw)
To: Jonas Karlman, Midgy BALON
Cc: iommu, joro, will, robin.murphy, heiko, linux-arm-kernel,
linux-rockchip, linux-kernel, stable
In-Reply-To: <e622cc9e-8fb0-454a-b88e-dc13cf2ff507@kwiboo.se>
Hi Jonas,
在 2026/4/1 16:41, Jonas Karlman 写道:
> Hi Simon,
>
> On 4/1/2026 9:48 AM, Simon wrote:
>> Hi Midgy,
>>
>> 在 2026/3/31 15:50, Midgy BALON 写道:
>>> commit 2a7e6400f72b ("iommu: rockchip: Allocate tables from all
>>> available memory for IOMMU v2") removed GFP_DMA32 from
>>> iommu_data_ops_v2, reasoning that RK356x and RK3588 IOMMU v2 hardware
>>> supports up to 40-bit physical addresses for page tables. However, the
>>> RK3568 IOMMU page-table walker uses a 32-bit AXI bus: it cannot access
>>> physical addresses above 4 GB regardless of the address encoding range.
>>>
>>> On boards with more than 4 GB of RAM (e.g. 8 GB LPDDR4X), removing
>>> GFP_DMA32 causes two distinct failure modes:
>>>
>>> 1. Direct allocation above 4 GB: iommu_alloc_pages_sz() may return
>>> memory above 0x100000000. The hardware page-table walker issues a
>>> bus error trying to dereference those addresses, causing an IOMMU
>>> fault on the first DMA transaction.
>> Which IP block is hitting this? We'd like to take a look on our end.
> I have seen reports that the NPU MMU on RK3568/RK3566 is having some
> issue using DTE/PTE with >32-bit addresses, maybe it uses a different
> MMU hw revision or has some hw errata?
>
> From my own testing at least the VOP2 MMU on RK3568 (and RK3588) was
> able to handle 40-bit addressable DTE/PTE, hence the original commit
> 2a7e6400f72b ("iommu: rockchip: Allocate tables from all available
> memory for IOMMU v2").
>
> As also mentioned in my reply at [1], maybe the NPU MMU has some hw
> limitation or errata and may need to use a different compatible.
Yes, We are checking internally whether different IOMMU versions
integrated.
I will share what we find once we have results.
> [1] https://lore.kernel.org/r/3cd63b3d-1c5e-4a11-856e-c4aeb5d97d55@kwiboo.se/
>
> Regards,
> Jonas
>
>>> 2. SWIOTLB bounce-buffer poisoning: without GFP_DMA32, page tables land
>>> above the SWIOTLB window. dma_map_single() with DMA_BIT_MASK(32)
>>> then bounces them into a buffer below 4 GB. rk_dte_get_page_table()
>>> returns phys_to_virt() of the bounce buffer address; PTEs are written
>>> there; the next dma_sync_single_for_device(DMA_TO_DEVICE) copies the
>>> original (zero) data back over the bounce buffer, silently erasing the
>>> freshly written PTEs. The IOMMU faults because every PTE reads as zero.
>> This probably need a separate patch. One way to fix it would be to track the
>> original L2 page table base addresses in struct rk_iommu_domain,
>> then have rk_dte_get_page_table() return the tracked address instead of
>> deriving it from the DTE.
>>
>>> Restore GFP_DMA32 (and DMA_BIT_MASK(32)) for iommu_data_ops_v2, which
>>> currently only serves "rockchip,rk3568-iommu" in mainline.
>>>
>>> Tested on Radxa ROCK 3B (RK3568, 8 GB LPDDR4X):
>>> - MobileNetV1 via RKNN: 5.8 ms/inference (IOMMU mode)
>>> - YOLOv5s 640x640 via RKNN: ~57 ms/inference (IOMMU mode)
>>> - No IOMMU faults, correct inference results
>>>
>>> Fixes: 2a7e6400f72b ("iommu: rockchip: Allocate tables from all available memory for IOMMU v2")
>>> Cc: stable@vger.kernel.org
>>> Cc: Jonas Karlman <jonas@kwiboo.se>
>>> Signed-off-by: Midgy BALON <midgy971@gmail.com>
>>> ---
>>> drivers/iommu/rockchip-iommu.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
>>> index 85f3667e797..8b45db29471 100644
>>> --- a/drivers/iommu/rockchip-iommu.c
>>> +++ b/drivers/iommu/rockchip-iommu.c
>>> @@ -1358,8 +1358,8 @@ static struct rk_iommu_ops iommu_data_ops_v2 = {
>>> .pt_address = &rk_dte_pt_address_v2,
>>> .mk_dtentries = &rk_mk_dte_v2,
>>> .mk_ptentries = &rk_mk_pte_v2,
>>> - .dma_bit_mask = DMA_BIT_MASK(40),
>>> - .gfp_flags = 0,
>>> + .dma_bit_mask = DMA_BIT_MASK(32),
>>> + .gfp_flags = GFP_DMA32,
>>> };
>>>
>>> static const struct of_device_id rk_iommu_dt_ids[] = {
>
^ permalink raw reply
* Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Liviu Dudau @ 2026-04-01 10:13 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707B3E37DFE7AEE587DBA2AF350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On Wed, Apr 01, 2026 at 09:43:12AM +0000, Guangliu Ding wrote:
> Hi Daniel
>
> > On 4/1/26 11:48, Guangliu Ding wrote:
> > > [You don't often get email from guangliu.ding@nxp.com. Learn why this
> > > is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Hi Liviu
> > >
> > > Thanks for your review. Please refer to my comments below:
> > >
> > >> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> > >>> Add compatible string of Mali G310 GPU on i.MX952 board.
> > >>>
> > >>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > >>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > >>> ---
> > >>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1
> > >>> +
> > >>> 1 file changed, 1 insertion(+)
> > >>>
> > >>> diff --git
> > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > >> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > >>> index 8eccd4338a2b..6a10843a26e2 100644
> > >>> ---
> > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > >>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yam
> > >>> +++ l
> > >>> @@ -20,6 +20,7 @@ properties:
> > >>> - enum:
> > >>> - mediatek,mt8196-mali
> > >>> - nxp,imx95-mali # G310
> > >>> + - nxp,imx952-mali # G310
> > >> Can you explain why this is needed? Can it not be covered by the
> > >> existing compatible?
> > > There are functional differences in GPU module (GPUMIX) between i.MX95
> > > and i.MX952. So they cannot be fully covered by a single existing compatible.
> > > On i.MX952, The GPU clock is controlled by hardware GPU auto
> > > clock-gating mechanism, while the GPU clock is managed explicitly by the
> > driver on i.MX95.
> > > Because of these behavioral differences, separate compatible strings
> > > "nxp,imx95-mali" and "nxp,imx952-mali" are needed to allow the driver
> > > to handle the two variants independently and to keep room for future
> > divergence.
> >
> >
> > This information should be added in the commit message explaining why
> >
> > the change is needed.
> >
> >
> > But then where is the driver code taking care of these diferences?
> >
>
> Yes. Currently the driver does not require "nxp,imx952-mali" string.
> However, when GPU ipa_counters are enabled to calculate the GPU busy_time/idle_time for
> GPU DVFS feature, they will conflict with the hardware GPU auto clock‑gating mechanism,
> causing GPU clock to remain always on.
> In such cases, ipa_counters need to be disabled so that the GPU auto clock‑gating
> mechanism can operate normally, using "nxp,imx952-mali" string.
OK, I understand that you're following guidance from some other senior people on how
to upstream patches so you've tried to create the smallest patchset to ensure that
it gets reviewed and accepted, but in this case we need to see the other patches as well
to decide if your approach is the right one and we do need a separate compatible string.
If enabling GPU ipa_counters causes the clocks to get stuck active, that feels like a
hardware bug, so figuring out how to handle that is more important than adding a compatible
string.
Either add the patch(es) that use the compatible to this series in v2, or put a comment in
the commit message on where we can see the driver changes.
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: imx952: Describe Mali G310 GPU
From: Guangliu Ding @ 2026-04-01 10:19 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding
In-Reply-To: <20260401-master-v2-0-20d3fbcd19d6@nxp.com>
Support Mali G310 GPU on i.MX952 board. Describe this GPU in the DT.
Include dummy GPU voltage regulator and OPP tables.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
---
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 +++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
index 91fe4916ac04..0bd3e7fc0674 100644
--- a/arch/arm64/boot/dts/freescale/imx952.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
@@ -318,6 +318,28 @@ usbphynop2: usbphynop2 {
clock-names = "main_clk";
};
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-hz-real = /bits/ 64 <500000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-hz-real = /bits/ 64 <800000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-hz-real = /bits/ 64 <1000000000>;
+ opp-microvolt = <920000>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -1262,5 +1284,19 @@ usbmisc2: usbmisc@4c200200 {
reg = <0x0 0x4c200200 0x0 0x200>,
<0x0 0x4c010014 0x0 0x4>;
};
+
+ gpu: gpu@4d900000 {
+ compatible = "nxp,imx952-mali", "arm,mali-valhall-csf";
+ reg = <0 0x4d900000 0 0x480000>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gpu", "job", "mmu";
+ clocks = <&scmi_clk IMX952_CLK_GPU>;
+ clock-names = "core";
+ power-domains = <&scmi_devpd IMX952_PD_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ dynamic-power-coefficient = <1013>;
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 10:19 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding
In-Reply-To: <20260401-master-v2-0-20d3fbcd19d6@nxp.com>
The GPU instance used on NXP i.MX952 is the Mali‑G310,
document support for this variant.
A hardware GPU auto clock‑gating mechanism has been introduced,
enabling GPUMIX to automatically manage the GPU clock. This improves
overall response time.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
---
Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index 8eccd4338a2b..6a10843a26e2 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -20,6 +20,7 @@ properties:
- enum:
- mediatek,mt8196-mali
- nxp,imx95-mali # G310
+ - nxp,imx952-mali # G310
- rockchip,rk3588-mali
- const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] Enable Mali G310 GPU support on i.MX952 board
From: Guangliu Ding @ 2026-04-01 10:19 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding
This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
IP as the instance on i.MX95 boards.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
---
Changes in v2:
- Improve patch description, adding more GPU information.
- Remove Reviewed-by tag.
- Link to v1: https://patch.msgid.link/20260331-master-v1-0-65c8e318d462@nxp.com
---
Guangliu Ding (2):
dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
arm64: dts: imx952: Describe Mali G310 GPU
.../bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 ++++++++++++++++++++++
2 files changed, 37 insertions(+)
---
base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
change-id: 20260331-master-7ec7ff0fe1b2
Best regards,
--
Guangliu Ding <guangliu.ding@nxp.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox