* Re: [PATCH v5 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Krzysztof Kozlowski @ 2026-03-31 6:58 UTC (permalink / raw)
To: Jianhua Lin
Cc: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu
In-Reply-To: <20260331005458.24010-2-jianhua.lin@mediatek.com>
On Tue, Mar 31, 2026 at 08:54:56AM +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG decoder block found in the
> MediaTek MT8189 SoC.
>
> Compared to previous generation ICs, the MT8189 JPEG decoder requires
> 34-bit IOVA address space support and only needs a single clock
> ("jpgdec") instead of two. Therefore, it is added as a standalone
> compatible string without falling back to older SoCs.
>
> Update the binding schema to include the new compatible string and add
> an `allOf` block with conditional checks. This enforces the single clock
> requirement for MT8189 while preserving the two-clock requirement
> ("jpgdec-smi", "jpgdec") for older SoCs.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
> 1 file changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> index a4aacd3eb189..601fe05b73e7 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> @@ -15,10 +15,10 @@ description: |-
> properties:
> compatible:
> oneOf:
> - - items:
> - - enum:
> - - mediatek,mt8173-jpgdec
> - - mediatek,mt2701-jpgdec
> + - enum:
> + - mediatek,mt2701-jpgdec
> + - mediatek,mt8173-jpgdec
> + - mediatek,mt8189-jpgdec
> - items:
> - enum:
> - mediatek,mt7623-jpgdec
> @@ -32,13 +32,22 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> maxItems: 2
> - minItems: 2
>
> clock-names:
> - items:
> - - const: jpgdec-smi
> - - const: jpgdec
> + minItems: 1
> + maxItems: 2
Why jpgdec-smi alone is now valid? Drop these two.
> + oneOf:
> + - items:
> + - const: jpgdec
> + - items:
> + - const: jpgdec-smi
> + - const: jpgdec
> +
> + mediatek,larb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: a phandle to the smi_larb node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 12/30] KVM: arm64: Hoist MTE validation check out of MMU lock path
From: Anshuman Khandual @ 2026-03-31 6:57 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-13-maz@kernel.org>
On 27/03/26 5:06 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Simplify the non-cacheable attributes assignment by using a ternary
> operator. Additionally, hoist the MTE validation check (mte_allowed) out
> of kvm_s2_fault_map() and into kvm_s2_fault_compute_prot(). This allows
> us to fail faster and avoid acquiring the KVM MMU lock unnecessarily
> when the VMM introduces a disallowed VMA for an MTE-enabled guest.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/mmu.c | 28 ++++++++++++----------------
> 1 file changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 0c71e3a9af8b0..ee2a548999b1b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1870,18 +1870,21 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> if (fault->exec_fault)
> fault->prot |= KVM_PGTABLE_PROT_X;
>
> - if (fault->s2_force_noncacheable) {
> - if (fault->vm_flags & VM_ALLOW_ANY_UNCACHED)
> - fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> - else
> - fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> - } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> + if (fault->s2_force_noncacheable)
> + fault->prot |= (fault->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
> + KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
> + else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
> fault->prot |= KVM_PGTABLE_PROT_X;
> - }
Is not the existing code block bit more cleaner though ?
>
> if (fault->nested)
> adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
>
> + if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm)) {
> + /* Check the VMM hasn't introduced a new disallowed VMA */
> + if (!fault->mte_allowed)
> + return -EFAULT;
> + }
> +
> return 0;
> }
>
> @@ -1918,15 +1921,8 @@ static int kvm_s2_fault_map(struct kvm_s2_fault *fault, void *memcache)
> }
> }
>
> - if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm)) {
> - /* Check the VMM hasn't introduced a new disallowed VMA */
> - if (fault->mte_allowed) {
> - sanitise_mte_tags(kvm, fault->pfn, fault->vma_pagesize);
> - } else {
> - ret = -EFAULT;
> - goto out_unlock;
> - }
> - }
> + if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm))
> + sanitise_mte_tags(kvm, fault->pfn, fault->vma_pagesize);
>
> /*
> * Under the premise of getting a FSC_PERM fault, we just need to relax
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Dmitry Torokhov @ 2026-03-31 6:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <acto3TE1AR8iTzF0@ashevche-desk.local>
On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
>> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
>> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
>
>...
>
>> > > -static void __exit software_node_exit(void)
>> > > -{
>> > > - ida_destroy(&swnode_root_ids);
>> > > - kset_unregister(swnode_kset);
>> > > }
>> > > -__exitcall(software_node_exit);
>> >
>> > Why? What's wrong with the __exitcall?
>>
>> It's dead code. Always was, always will be.
>>
>> Maybe split in a separate patch, but I sometimes feel the idea of "one
>> change" is taken to extreme and adds to both developer's and maintainers
>> burden by needing to keep track of extra patches.
>
>Why does __exitcall() exist then? It's also used in other places.
>I think it's generally good to have a possibility to clean up
>after run.
>
The code section will be discarded when the kernel finishes booting so it only increases image size on disk.
>A bit of archaeology:
>
>The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
>Then somehow spread a bit (but not much).
>
And it shows how useful it is. Maybe it had some purpose a long time ago, but at present time this code will never be executed since it cannot be built as a module.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace
From: bigeasy @ 2026-03-31 6:52 UTC (permalink / raw)
To: Maninder Singh
Cc: Russell King (Oracle), peterz@infradead.org, kees@kernel.org,
ardb@kernel.org, keithpac@amazon.com, linusw@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260309055328epcms5p56d16f6cb1e3a5295987c935f35be1d2e@epcms5p5>
On 2026-03-09 11:23:28 [+0530], Maninder Singh wrote:
> Hi,
Hi,
> >"otherwise if someone calls show_stack() for task" ... and the stack
> >trace given stops at show_stack() and doesn't show the "someone".
> >
> >I'd like to know _how_ this happens, and why ARM64 and now 32-bit ARM
> >are different from x86.
>
> I tried to simulate same thing on x86_64, it is also crashing.
>
> Just a dummy code to save task_struct to reproduce the race:
>
> + rcu_read_lock();
> + for_each_process(p) {
> + if (!strcmp(p->comm, "sleep")) {
> + check_task = p;
> + get_task_struct(p);
> + pr_emerg("get done for %s %d\n", p->comm, p->pid);
> + }
> + }
> + rcu_read_unlock();
>
> // in mean time here sleep binary will be exited.
>
> + show_stack(check_task, NULL, KERN_EMERG);
The task's stack is released on its final schedule() invocation.
Therefore holding task_struct does not hold the stack of the task if it
is separated out of task_struct and can be gone if the tasks quits.
Therefore holding a reference to the stack while accessing it, like
during a backtrace, makes sense and is required if the task is not
current.
Let me add this to my list and tackle it later today for x86. Then we
get probably Russell on board for ARM.
> //OOPs
Sebastian
^ permalink raw reply
* Re: [PATCH 5/5] lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
From: Christoph Hellwig @ 2026-03-31 6:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto, linux-arm-kernel, Demian Shulhan, Eric Biggers
In-Reply-To: <20260330144630.33026-12-ardb@kernel.org>
> depends on CRC64 && CRC_OPTIMIZATIONS
> + default y if ARM && KERNEL_MODE_NEON && !(CPU_BIG_ENDIAN && CC_IS_CLANG)
It would be useful to throw in a comment here why it is disabled for
big-endian on clang.
> +#define crc64_be_arch crc64_be_generic
> +
> +static inline u64 crc64_nvme_arch(u64 crc, const u8 *p, size_t len)
> +{
> + if (len >= 128 && static_branch_likely(&have_pmull) &&
> + likely(may_use_simd())) {
> + do {
> + size_t chunk = min_t(size_t, len & ~15, SZ_4K);
> +
> + scoped_ksimd()
> + crc = crc64_nvme_arm64_c(crc, p, chunk);
> +
> + p += chunk;
> + len -= chunk;
> + } while (len >= 128);
> + }
From reading the earlier patches, I'll assume arm SIMD code is
non-preemptable and thus you want the chunking here? Maybe add
a little comment explaining that?
^ permalink raw reply
* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Krzysztof Kozlowski @ 2026-03-31 6:47 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel, linux-i2c,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
In-Reply-To: <20260330-upstream_i2c-v28-2-17bdae39c5cb@aspeedtech.com>
On Mon, Mar 30, 2026 at 04:21:47PM +0800, Ryan Chen wrote:
> Add aspeed,enable-dma boolean property to indicate that DMA is
> available for transfers on this I2C bus.
>
> Also add the aspeed,global-regs phandle to reference the AST2600
> global registers syscon node, containing the SoC-common I2C register
> set.
>
> These properties apply only to the AST2600 binding. Legacy DTs remain
> unchanged.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v28:
> - update commit message correspond with aspeed,enable-dma.
> - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> description.
> - Fix aspeed,enable-dma description to reflect hardware capability rather
> than software behavior
> Changes in v27:
> - change aspeed,transfer-mode to aspeed,enable-dma.
> ---
> .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> index de2c359037da..67b23d1a4cec 100644
> --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> @@ -37,6 +37,16 @@ properties:
> resets:
> maxItems: 1
>
> + aspeed,enable-dma:
> + type: boolean
> + description: Indicates this I2C controller instance has DMA capability.
Compatible implies that "I2C controller instance has DMA capability", no?
How two same devices, with exactly the same or compatible programming
model can have difference in the programming model for DMA (one lacks
it)?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Jie Zhan @ 2026-03-31 6:43 UTC (permalink / raw)
To: Yaxiong Tian, cw00.choi, myungjoo.ham, kyungmin.park
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <94f5b6ff-f610-44f6-90e4-2e538b4f99c9@kylinos.cn>
On 3/31/2026 9:30 AM, Yaxiong Tian wrote:
>
> 在 2026/3/30 14:29, Jie Zhan 写道:
>>
>> On 3/27/2026 10:06 AM, Yaxiong Tian wrote:
>>> 在 2026/3/26 21:14, Jie Zhan 写道:
>>>> On 3/26/2026 8:34 PM, Jie Zhan wrote:
>>>>> When compiled as a kernel module, the governor module can be dynamically
>>>>> inserted or removed. 'devfreq->governor' would become NULL if the governor
>>>>> module is removed when it's in use, and NULL pointer dereference would be
>>>>> triggered. A similar issue was also reported in [1].
>>>>>
>>>>> To address this issue:
>>>>>
>>>>> Patch 1-5 rework mutex, factor out a common governor setting function, and
>>>>> clean up some unreachable code.
>>>>>
>>>>> Patch 6-8 prevent a governor module in use from being removed (except for
>>>>> force unload) by getting/putting a refcount of the governor's module when
>>>>> switching governors.
>>>>>
>>>>> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
>>>>> when a governor module in use is force unloaded.
>>>>>
>>>>> Note that this series is based on [1] or devfreq-next, otherwise code
>>> Sorry, please ignore the "remember to CC me on the patches." in my previous email.
>>>
>>> In my opinion, it would be better to prioritize the FIX first before proceeding with the lock mechanism optimizations and other work. This would make it easier to backport the patches to lower-version kernels. I noticed the patch is already in the devfreq-testing branch. I hope the FIX work can be moved forward smoothly to resolve the null pointer and other bugs. Thank you!
>> Hi Yaxiong,
>>
>> I don't think this issue is urgent because it can only possibly happen when
>> governors are built as loadable modules, which is typically used for
>> development rather than production.
> No, loading/unloading modules is also a user operational requirement, not just for development.
>
>>
>> For downstream kernels, feel free to go ahead with quick fixes. For the
>> upstream kernel, however, I'd prefer to make the devfreq core clean and
>> sensible.
>
> I don't think code cleanup should take priority over bug fixes, especially when you already know there's an issue with the functionality. In fact, the version users are running is not the upstream version, but rather individual stable releases.
The point is to do the bugfix in a different way rather than cleanups.
>
> Most users don't have the time or energy to research and fix kernel issues themselves; they rely on upstream community patches most of the time.
>
> By the way, although your patch subject says "FIX", I don't see any fix tag.
>
>>
>> Your approach is to prevent kernel panics when unloading governor modules
>> before changing governors.
>>
>> This patchset achieves that, and additionally let userspace get a friendly
>> warning when trying to remove a governor module in use, e.g.
>> "rmmod: ERROR: Module governor_performance is in use".
>> This requires using the module refcount stuff, and brings out a set of
>> cleanups and refactoring. BTW, cpufreq implements a similar mechanism like
>> this.
>>
>> I may carry your fourth patch that changes the return code of
>> governor_show() in v2 and address some Sashiko review comments along the
>> way.
>>
>> Please let me know if this works for you?
> So I don't approve of this. Maybe you should ask for others' opinions, such as Chanwoo Choi.
>
No problem. I see your point.
I'll take a closer look at your version and see if that works.
The module owner refcount related stuff can be rebased later if needed.
Thanks,
Jie
>>
>> Regards,
>> Jie
>>>
>>>
>>>> sorry, based on [2] or devfreq-next
>>>>> would conflict.
>>>>>
>>>>> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
>>>>> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Manivannan Sadhasivam @ 2026-03-31 6:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Manivannan Sadhasivam, mark.rutland, lpieralisi, bjorn.andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, Konrad Dybcio,
Konrad Dybcio, Sudeep Holla
In-Reply-To: <acrdFfk8al80dynq@baldur>
On Mon, Mar 30, 2026 at 03:48:05PM -0500, Bjorn Andersson wrote:
> On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
> > From: Konrad Dybcio <konradybcio@kernel.org>
> >
> > PSCI specification defines the SYSTEM_SUSPEND feature which enables the
> > firmware to implement the suspend to RAM (S2RAM) functionality by
> > transitioning the system to a deeper low power state. When the system
> > enters such state, the power to the peripheral devices might be removed.
>
> What is the actual extent of "peripheral devices" in this definition?
>
All devices except the ones backing volatile memory (DDR).
> > So
> > the respective device drivers must prepare for the possible removal of the
> > power by performing actions such as shutting down or resetting the device
> > in their system suspend callbacks.
> >
>
> Our typical interpretation of this state is that IP-blocks might be
> non-functional during this time, but typically some state is retained.
>
> Will the acceptance of this patch result in that we in the Qualcomm case
> should start accepting/writing patches that implement save/restore of
> state that is generally retained throughout the drivers - in the name of
> "power might be removed"?
>
From the PSCI spec perspective, the underlying implementation of the
SYSTEM_SUSPEND is implementation defined. So whether the vendor firmware retains
the state or drops it completely, is out of the scope for PSCI. That's why
*assuming* that the devices will loose power is the best possible approach.
For sure, assuming that the power will be lost always will result in some
overhead with drivers saving and restoring the context unnecessarily if the
power if retained. But I can't think of any other way to make the driver work
across all firmware implementations.
> > The Linux PM framework allows the platform drivers to convey this info to
> > device drivers by calling the pm_set_suspend_via_firmware() and
> > pm_set_resume_via_firmware() APIs.
> >
> > Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
> > mentioned APIs in the psci_system_suspend_begin() and
> > psci_system_suspend_enter() callbacks.
> >
>
> With the right interpretation of what this means for us, I think this
> patch looks good - but as we've discussed, I'm a bit worried about how
> to deal with the alternative interpretations.
>
Just for the sake of clarity to others, 'alternative interpretations' is
referring to Qcom DeepSleep firmware implementation, which cuts power to almost
all components except DDR with no wakeup source other than PMIC.
> Specifically, if we fully adopt "power might be removed", we should to
> take actions which will prevent a typical Qualcomm system from waking up
> from sleep again.
>
I think for wakeup, the driver should just save the device context and call
enable_irq_wake() if the user has configured the device as a wakeup source and
assume that the device will wakeup the system from suspend/sleep.
The underlying firmware should honor the wakeup and not cut the power to the
devices. But if it does, then wakeup will be broken anyway.
So from Qcom drivers perspective:
1. They should save and restore the context if those drivers are going to be
used in both PSCI SYSTEM_SUSPEND (power retained) and DeepSleep (power lost)
firmware implementations.
2. If the user has configured wakeup, they should enable wakeup using
enable_irq_wake() during suspend. On PSCI SYSTEM_SUSPEND implementations, wakeup
should just work, but on DeepSleep, it may not if the power is cut off
completely. But that's the limitation on those platforms and the OS policy
should ensure that wakeup is not configured for devices.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2] raid6: arm64: add SVE optimized implementation for syndrome generation
From: Christoph Hellwig @ 2026-03-31 6:36 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Demian Shulhan, Mark Rutland, Christoph Hellwig, Song Liu,
Yu Kuai, Will Deacon, Catalin Marinas, Mark Brown,
linux-arm-kernel, robin.murphy, Li Nan, linux-raid, linux-kernel
In-Reply-To: <9a12e043-8200-4650-bfe2-cbece57a4f87@app.fastmail.com>
On Mon, Mar 30, 2026 at 06:39:49PM +0200, Ard Biesheuvel wrote:
> I think the results are impressive, but I'd like to better understand
> its implications on a real-world scenario. Is this code only a
> bottleneck when rebuilding an array?
The syndrome generation is run every time you write data to a RAID6
array, and if you do partial stripe writes it (or rather the XOR
variant) is run twice. So this is the most performance critical
path for writing to RAID6.
Rebuild usually runs totally different code, but can end up here as well
when both parity disks are lost.
> > Furthermore, as Christoph suggested, I tested scalability on wider
> > arrays since the default kernel benchmark is hardcoded to 8 disks,
> > which doesn't give the unrolled SVE loop enough data to shine. On a
> > 16-disk array, svex4 hits 15.1 GB/s compared to 8.0 GB/s for neonx4.
> > On a 24-disk array, while neonx4 chokes and drops to 7.8 GB/s, svex4
> > maintains a stable 15.0 GB/s — effectively doubling the throughput.
>
> Does this mean the kernel benchmark is no longer fit for purpose? If
> it cannot distinguish between implementations that differ in performance
> by a factor of 2, I don't think we can rely on it to pick the optimal one.
It is not good, and we should either fix it or run more than one.
The current setup is not really representative of real-life array.
It also leads to wrong selections on x86, but only at the which unroll
level to pick level, and only for minor differences so far. I plan
to add this to the next version of the raid6 lib patches.
^ permalink raw reply
* Re: [PATCH v2 11/30] KVM: arm64: Optimize early exit checks in kvm_s2_fault_pin_pfn()
From: Anshuman Khandual @ 2026-03-31 6:35 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-12-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Optimize the early exit checks in kvm_s2_fault_pin_pfn by grouping all
> error responses under the generic is_error_noslot_pfn check first,
> avoiding unnecessary branches in the hot path.
>
> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 2b85daaa4426b..0c71e3a9af8b0 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1791,12 +1791,13 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> fault->pfn = __kvm_faultin_pfn(fault->memslot, fault->gfn,
> fault->write_fault ? FOLL_WRITE : 0,
> &fault->writable, &fault->page);
> - if (fault->pfn == KVM_PFN_ERR_HWPOISON) {
> - kvm_send_hwpoison_signal(fault->hva, __ffs(fault->vma_pagesize));
> - return 0;
> - }
> - if (is_error_noslot_pfn(fault->pfn))
> + if (unlikely(is_error_noslot_pfn(fault->pfn))) {
> + if (fault->pfn == KVM_PFN_ERR_HWPOISON) {
> + kvm_send_hwpoison_signal(fault->hva, __ffs(fault->vma_pagesize));
> + return 0;
> + }
> return -EFAULT;
> + }
>
> return 1;
> }
^ permalink raw reply
* Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive
From: Vishnu Pajjuri @ 2026-03-31 6:31 UTC (permalink / raw)
To: Marc Zyngier
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Christoffer Dall, Mark Brown, kvm, linux-arm-kernel,
kvmarm
In-Reply-To: <878qb9cxzr.wl-maz@kernel.org>
Hi Marc,
Many thanks for your reply.
On 30-03-2026 17:47, Marc Zyngier wrote:
> On Mon, 30 Mar 2026 12:51:51 +0100,
> Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
>>
>> Hi Fuad Tabba,
>
> To be brutally honest, I doubt Fuad really cares about NV,
I see Tested-by: fuad Tabba on this patch so tried to reach out him.
>
>> I'm trying to run nested VMs on Ampere platforms after this patch
>> series(v6.19+) but nested VMs are not booting and triggering soft
>> lockups on L0 and L0 hang. But just before this patch I could able to
>> successfully boot the Nested VMs.
>
> So the host dies? There isn't much here that interacts with the host
> at all. Worse case, the L1 dies by not making progress.
Initially L1 become unresponsive then L0 becomes unresponsive, soft
lockups and L0 hang.
>
>>
>> I bisected the failure to a single commit which is this patch which is
>> causing the issue.
>>
>> I would like to understand from you that did you observed anything
>> like that?
>
> No. If I had, I wouldn't have merged the series.
>
>>
>> Were you able to boot Nested VMs successfully after v6.19+?
>
> I boot L3s every day.
Do you mean L2s or L3s on top of L2s?
I running L1 and L2 using latest QEMU, do you use QEMU or kvmtool run L1
and L2 in your regression tests?
>
>> LOG:
>> [ 164.647367] Call trace:
>> [ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P)
>> [ 164.647372] smp_call_function_many+0x20/0x40
>> [ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8
>> [ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8
>> [ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0
>> [ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400
>> [ 164.647386] kvm_vm_ioctl+0x7b8/0xc88
>> [ 164.647389] __arm64_sys_ioctl+0xb4/0x118
>> [ 164.647393] invoke_syscall+0x6c/0x100
>> [ 164.647397] el0_svc_common.constprop.0+0x48/0xf0
>> [ 164.647398] do_el0_svc+0x24/0x38
>> [ 164.647400] el0_svc+0x3c/0x170
>> [ 164.647403] el0t_64_sync_handler+0xa0/0xe8
>> [ 164.647405] el0t_64_sync+0x1b0/0x1b8
>
> This trace is about interrupt injection from userspace, not
> deactivation of a HW interrupt.
> None of that makes much sense.
Although this behavior is puzzling, it matches the trace I typically
observe on L0. After reverting the patch, I was able to boot L2 guests
successfully.
Regards,
-Vishnu
>
> M.
>
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Andy Shevchenko @ 2026-03-31 6:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <acruxMNdnUlyRHiy@google.com>
On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
...
> > > -static void __exit software_node_exit(void)
> > > -{
> > > - ida_destroy(&swnode_root_ids);
> > > - kset_unregister(swnode_kset);
> > > }
> > > -__exitcall(software_node_exit);
> >
> > Why? What's wrong with the __exitcall?
>
> It's dead code. Always was, always will be.
>
> Maybe split in a separate patch, but I sometimes feel the idea of "one
> change" is taken to extreme and adds to both developer's and maintainers
> burden by needing to keep track of extra patches.
Why does __exitcall() exist then? It's also used in other places.
I think it's generally good to have a possibility to clean up
after run.
A bit of archaeology:
The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
Then somehow spread a bit (but not much).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 10/30] KVM: arm64: Initialize struct kvm_s2_fault completely at declaration
From: Anshuman Khandual @ 2026-03-31 5:43 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-11-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Simplify the initialization of struct kvm_s2_fault in user_mem_abort().
>
> Instead of partially initializing the struct via designated initializers
> and then sequentially assigning the remaining fields (like write_fault
> and topup_memcache) further down the function, evaluate those
> dependencies upfront.
>
> This allows the entire struct to be fully initialized at declaration. It
> also eliminates the need for the intermediate fault_data variable and
> its associated fault pointer, reducing boilerplate.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 34 ++++++++++++++++------------------
> 1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index e77b0b60697f6..2b85daaa4426b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1962,8 +1962,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_memory_slot *memslot, unsigned long hva,
> bool fault_is_perm)
> {
> - int ret = 0;
> - struct kvm_s2_fault fault_data = {
> + bool write_fault = kvm_is_write_fault(vcpu);
> + bool logging_active = memslot_is_logging(memslot);
> + struct kvm_s2_fault fault = {
> .vcpu = vcpu,
> .fault_ipa = fault_ipa,
> .nested = nested,
> @@ -1971,19 +1972,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> .hva = hva,
> .fault_is_perm = fault_is_perm,
> .ipa = fault_ipa,
> - .logging_active = memslot_is_logging(memslot),
> - .force_pte = memslot_is_logging(memslot),
> - .s2_force_noncacheable = false,
> + .logging_active = logging_active,
> + .force_pte = logging_active,
> .prot = KVM_PGTABLE_PROT_R,
> + .fault_granule = fault_is_perm ? kvm_vcpu_trap_get_perm_fault_granule(vcpu) : 0,
> + .write_fault = write_fault,
> + .exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu),
> + .topup_memcache = !fault_is_perm || (logging_active && write_fault),
> };
> - struct kvm_s2_fault *fault = &fault_data;
> void *memcache;
> + int ret;
>
> - if (fault->fault_is_perm)
> - fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu);
> - fault->write_fault = kvm_is_write_fault(fault->vcpu);
> - fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu);
> - VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault);
> + VM_WARN_ON_ONCE(fault.write_fault && fault.exec_fault);
>
> /*
> * Permission faults just need to update the existing leaf entry,
> @@ -1991,9 +1991,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * only exception to this is when dirty logging is enabled at runtime
> * and a write fault needs to collapse a block entry into a table.
> */
> - fault->topup_memcache = !fault->fault_is_perm ||
> - (fault->logging_active && fault->write_fault);
> - ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache);
> + ret = prepare_mmu_memcache(vcpu, fault.topup_memcache, &memcache);
> if (ret)
> return ret;
>
> @@ -2001,17 +1999,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * Let's check if we will get back a huge page backed by hugetlbfs, or
> * get block mapping for device MMIO region.
> */
> - ret = kvm_s2_fault_pin_pfn(fault);
> + ret = kvm_s2_fault_pin_pfn(&fault);
> if (ret != 1)
> return ret;
>
> - ret = kvm_s2_fault_compute_prot(fault);
> + ret = kvm_s2_fault_compute_prot(&fault);
> if (ret) {
> - kvm_release_page_unused(fault->page);
> + kvm_release_page_unused(fault.page);
> return ret;
> }
>
> - return kvm_s2_fault_map(fault, memcache);
> + return kvm_s2_fault_map(&fault, memcache);
> }
>
> /* Resolve the access fault by making the page young again. */
^ permalink raw reply
* Re: [PATCH v2 09/30] KVM: arm64: Simplify return logic in user_mem_abort()
From: Anshuman Khandual @ 2026-03-31 4:32 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-10-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> With the refactoring done, the final return block of user_mem_abort()
> can be tidied up a bit more.
>
> Clean up the trailing edge by dropping the unnecessary assignment,
> collapsing the return evaluation for kvm_s2_fault_compute_prot(), and
> tail calling kvm_s2_fault_map() directly.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 17 ++++-------------
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1b991300735be..e77b0b60697f6 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2005,22 +2005,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> if (ret != 1)
> return ret;
>
> - ret = 0;
> -
> ret = kvm_s2_fault_compute_prot(fault);
> - if (ret == 1) {
> - ret = 1; /* fault injected */
> - goto out_put_page;
> + if (ret) {
> + kvm_release_page_unused(fault->page);
> + return ret;
> }
> - if (ret)
> - goto out_put_page;
>
> - ret = kvm_s2_fault_map(fault, memcache);
> - return ret;
> -
> -out_put_page:
> - kvm_release_page_unused(fault->page);
> - return ret;
> + return kvm_s2_fault_map(fault, memcache);
> }
>
> /* Resolve the access fault by making the page young again. */
^ permalink raw reply
* Re: [PATCH v2 08/30] KVM: arm64: Remove redundant state variables from struct kvm_s2_fault
From: Anshuman Khandual @ 2026-03-31 4:08 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-9-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Remove redundant variables vma_shift and vfio_allow_any_uc from struct
> kvm_s2_fault as they are easily derived or checked when needed.
> > Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 5572b127f8663..1b991300735be 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1721,10 +1721,8 @@ struct kvm_s2_fault {
> bool mte_allowed;
> bool is_vma_cacheable;
> bool s2_force_noncacheable;
> - bool vfio_allow_any_uc;
> unsigned long mmu_seq;
> phys_addr_t ipa;
> - short vma_shift;
> gfn_t gfn;
> kvm_pfn_t pfn;
> bool logging_active;
> @@ -1749,9 +1747,9 @@ static int kvm_s2_fault_get_vma_info(struct kvm_s2_fault *fault)
> return -EFAULT;
> }
>
> - fault->vma_shift = kvm_s2_resolve_vma_size(vma, fault->hva, fault->memslot, fault->nested,
> - &fault->force_pte, &fault->ipa);
> - fault->vma_pagesize = 1UL << fault->vma_shift;
> + fault->vma_pagesize = 1UL << kvm_s2_resolve_vma_size(vma, fault->hva, fault->memslot,
> + fault->nested, &fault->force_pte,
> + &fault->ipa);
>
> /*
> * Both the canonical IPA and fault IPA must be aligned to the
> @@ -1764,8 +1762,6 @@ static int kvm_s2_fault_get_vma_info(struct kvm_s2_fault *fault)
> fault->gfn = fault->ipa >> PAGE_SHIFT;
> fault->mte_allowed = kvm_vma_mte_allowed(vma);
>
> - fault->vfio_allow_any_uc = vma->vm_flags & VM_ALLOW_ANY_UNCACHED;
> -
> fault->vm_flags = vma->vm_flags;
>
> fault->is_vma_cacheable = kvm_vma_is_cacheable(vma);
> @@ -1796,7 +1792,7 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> fault->write_fault ? FOLL_WRITE : 0,
> &fault->writable, &fault->page);
> if (fault->pfn == KVM_PFN_ERR_HWPOISON) {
> - kvm_send_hwpoison_signal(fault->hva, fault->vma_shift);
> + kvm_send_hwpoison_signal(fault->hva, __ffs(fault->vma_pagesize));
> return 0;
> }
> if (is_error_noslot_pfn(fault->pfn))
> @@ -1874,7 +1870,7 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> fault->prot |= KVM_PGTABLE_PROT_X;
>
> if (fault->s2_force_noncacheable) {
> - if (fault->vfio_allow_any_uc)
> + if (fault->vm_flags & VM_ALLOW_ANY_UNCACHED)
> fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> else
> fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> @@ -1978,7 +1974,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> .logging_active = memslot_is_logging(memslot),
> .force_pte = memslot_is_logging(memslot),
> .s2_force_noncacheable = false,
> - .vfio_allow_any_uc = false,
> .prot = KVM_PGTABLE_PROT_R,
> };
> struct kvm_s2_fault *fault = &fault_data;
^ permalink raw reply
* Re: [PATCH v2 07/30] KVM: arm64: Simplify nested VMA shift calculation
From: Anshuman Khandual @ 2026-03-31 3:56 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-8-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> In the kvm_s2_resolve_vma_size() helper, the local variable vma_pagesize
> is calculated from vma_shift, only to be used to bound the vma_pagesize
> by max_map_size and subsequently convert it back to a shift via __ffs().
>
> Because vma_pagesize and max_map_size are both powers of two, we can
> simplify the logic by omitting vma_pagesize entirely and bounding the
> vma_shift directly using the shift of max_map_size. This achieves the
> same result while keeping the size-to-shift conversion out of the helper
> logic.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 164f1160ea33d..5572b127f8663 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1646,7 +1646,6 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> bool *force_pte, phys_addr_t *ipa)
> {
> short vma_shift;
> - long vma_pagesize;
>
> if (*force_pte)
> vma_shift = PAGE_SHIFT;
> @@ -1677,8 +1676,6 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> WARN_ONCE(1, "Unknown vma_shift %d", vma_shift);
> }
>
> - vma_pagesize = 1UL << vma_shift;
> -
> if (nested) {
> unsigned long max_map_size;
>
> @@ -1703,8 +1700,7 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> max_map_size = PAGE_SIZE;
>
> *force_pte = (max_map_size == PAGE_SIZE);
> - vma_pagesize = min_t(long, vma_pagesize, max_map_size);
> - vma_shift = __ffs(vma_pagesize);
> + vma_shift = min_t(short, vma_shift, __ffs(max_map_size));
> }
>
> return vma_shift;
^ permalink raw reply
* Re: [PATCH v2 06/30] KVM: arm64: Extract page table mapping in user_mem_abort()
From: Anshuman Khandual @ 2026-03-31 3:45 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-7-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Extract the code responsible for locking the KVM MMU and mapping the PFN
> into the stage-2 page tables into a new helper, kvm_s2_fault_map().
>
> This helper manages the kvm_fault_lock, checks for MMU invalidation
> retries, attempts to adjust for transparent huge pages (THP), handles
> MTE sanitization if needed, and finally maps or relaxes permissions on
> the stage-2 entries.
>
> With this change, the main user_mem_abort() function is now a sequential
> dispatcher that delegates to specialized helper functions.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 128 +++++++++++++++++++++++--------------------
> 1 file changed, 68 insertions(+), 60 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d1ffdce18631a..164f1160ea33d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1892,68 +1892,13 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> return 0;
> }
>
> -static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> - struct kvm_s2_trans *nested,
> - struct kvm_memory_slot *memslot, unsigned long hva,
> - bool fault_is_perm)
> +static int kvm_s2_fault_map(struct kvm_s2_fault *fault, void *memcache)
> {
> - int ret = 0;
> - struct kvm_s2_fault fault_data = {
> - .vcpu = vcpu,
> - .fault_ipa = fault_ipa,
> - .nested = nested,
> - .memslot = memslot,
> - .hva = hva,
> - .fault_is_perm = fault_is_perm,
> - .ipa = fault_ipa,
> - .logging_active = memslot_is_logging(memslot),
> - .force_pte = memslot_is_logging(memslot),
> - .s2_force_noncacheable = false,
> - .vfio_allow_any_uc = false,
> - .prot = KVM_PGTABLE_PROT_R,
> - };
> - struct kvm_s2_fault *fault = &fault_data;
> - struct kvm *kvm = vcpu->kvm;
> - void *memcache;
> + struct kvm *kvm = fault->vcpu->kvm;
> struct kvm_pgtable *pgt;
> + int ret;
> enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
>
> - if (fault->fault_is_perm)
> - fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu);
> - fault->write_fault = kvm_is_write_fault(fault->vcpu);
> - fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu);
> - VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault);
> -
> - /*
> - * Permission faults just need to update the existing leaf entry,
> - * and so normally don't require allocations from the memcache. The
> - * only exception to this is when dirty logging is enabled at runtime
> - * and a write fault needs to collapse a block entry into a table.
> - */
> - fault->topup_memcache = !fault->fault_is_perm ||
> - (fault->logging_active && fault->write_fault);
> - ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache);
> - if (ret)
> - return ret;
> -
> - /*
> - * Let's check if we will get back a huge page backed by hugetlbfs, or
> - * get block mapping for device MMIO region.
> - */
> - ret = kvm_s2_fault_pin_pfn(fault);
> - if (ret != 1)
> - return ret;
> -
> - ret = 0;
> -
> - ret = kvm_s2_fault_compute_prot(fault);
> - if (ret == 1) {
> - ret = 1; /* fault injected */
> - goto out_put_page;
> - }
> - if (ret)
> - goto out_put_page;
> -
> kvm_fault_lock(kvm);
> pgt = fault->vcpu->arch.hw_mmu->pgt;
> if (mmu_invalidate_retry(kvm, fault->mmu_seq)) {
> @@ -2001,8 +1946,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> * PTE, which will be preserved.
> */
> fault->prot &= ~KVM_NV_GUEST_MAP_SZ;
> - ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault->fault_ipa, fault->prot,
> - flags);
> + ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault->fault_ipa,
> + fault->prot, flags);
> } else {
> ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault->fault_ipa, fault->vma_pagesize,
> __pfn_to_phys(fault->pfn), fault->prot,
> @@ -2018,6 +1963,69 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> mark_page_dirty_in_slot(kvm, fault->memslot, fault->gfn);
>
> return ret != -EAGAIN ? ret : 0;
> +}
> +
> +static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> + struct kvm_s2_trans *nested,
> + struct kvm_memory_slot *memslot, unsigned long hva,
> + bool fault_is_perm)
> +{
> + int ret = 0;
> + struct kvm_s2_fault fault_data = {
> + .vcpu = vcpu,
> + .fault_ipa = fault_ipa,
> + .nested = nested,
> + .memslot = memslot,
> + .hva = hva,
> + .fault_is_perm = fault_is_perm,
> + .ipa = fault_ipa,
> + .logging_active = memslot_is_logging(memslot),
> + .force_pte = memslot_is_logging(memslot),
> + .s2_force_noncacheable = false,
> + .vfio_allow_any_uc = false,
> + .prot = KVM_PGTABLE_PROT_R,
> + };
> + struct kvm_s2_fault *fault = &fault_data;
> + void *memcache;
> +
> + if (fault->fault_is_perm)
> + fault->fault_granule = kvm_vcpu_trap_get_perm_fault_granule(fault->vcpu);
> + fault->write_fault = kvm_is_write_fault(fault->vcpu);
> + fault->exec_fault = kvm_vcpu_trap_is_exec_fault(fault->vcpu);
> + VM_WARN_ON_ONCE(fault->write_fault && fault->exec_fault);
> +
> + /*
> + * Permission faults just need to update the existing leaf entry,
> + * and so normally don't require allocations from the memcache. The
> + * only exception to this is when dirty logging is enabled at runtime
> + * and a write fault needs to collapse a block entry into a table.
> + */
> + fault->topup_memcache = !fault->fault_is_perm ||
> + (fault->logging_active && fault->write_fault);
> + ret = prepare_mmu_memcache(fault->vcpu, fault->topup_memcache, &memcache);
> + if (ret)
> + return ret;
> +
> + /*
> + * Let's check if we will get back a huge page backed by hugetlbfs, or
> + * get block mapping for device MMIO region.
> + */
> + ret = kvm_s2_fault_pin_pfn(fault);
> + if (ret != 1)
> + return ret;
> +
> + ret = 0;
> +
> + ret = kvm_s2_fault_compute_prot(fault);
> + if (ret == 1) {
> + ret = 1; /* fault injected */
> + goto out_put_page;
> + }
> + if (ret)
> + goto out_put_page;
> +
> + ret = kvm_s2_fault_map(fault, memcache);
> + return ret;
>
> out_put_page:
> kvm_release_page_unused(fault->page);
^ permalink raw reply
* RE: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Hongxing Zhu @ 2026-03-31 3:37 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Qiang Yu
In-Reply-To: <5nom7wnhrr57jvb6komumg3fjkbavsq5ecz2pd43rc5tsmnqev@ag6ld453s2lu>
> -----Original Message-----
> From: Manivannan Sadhasivam <mani@kernel.org>
> Sent: 2026年3月30日 18:19
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> lpieralisi@kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> bhelgaas@google.com; s.hauer@pengutronix.de; kernel@pengutronix.de;
> festevam@gmail.com; linux-pci@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev;
> linux-kernel@vger.kernel.org; stable@vger.kernel.org; Qiang Yu
> <qiang.yu@oss.qualcomm.com>
> Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> i.MX7D/i.MX8M
>
> On Mon, Mar 30, 2026 at 09:02:57AM +0000, Hongxing Zhu wrote:
> > > -----Original Message-----
> > > From: Manivannan Sadhasivam <mani@kernel.org>
> > > Sent: 2026年3月30日 15:23
> > > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > > Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> > > lpieralisi@kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> > > bhelgaas@google.com; s.hauer@pengutronix.de;
> kernel@pengutronix.de;
> > > festevam@gmail.com; linux-pci@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org;
> > > imx@lists.linux.dev; linux-kernel@vger.kernel.org;
> > > stable@vger.kernel.org; Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> > > i.MX7D/i.MX8M
> > >
> > > + Qiang
> > >
> > > On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > > > The MSI trigger mechanism for endpoint devices connected to
> > > > i.MX7D, i.MX8MM, and i.MX8MQ PCIe root complex ports depends on
> > > > the MSI capability register settings in the root complex. Removing
> > > > the MSI capability breaks MSI functionality for these endpoints.
> > > >
> > >
> > > What is the relation between Root Port MSI and endpoint MSI?
> > > Endpoint MSIs should be routed to the platform MSI controller (DWC
> > > i.MSI-RX or External like
> > > GIC-ITS) independent of the Root Port MSI state.
> > Hi Mani:
> > Thank for your kindly concern.
> > The MSI controller (DWC i.MSI-RX) on i.MX7D, i.MX8MM, and i.MX8MQ
> > platforms requires the RC's MSI capability to remain enabled. Removing
> > it breaks MSI routing from endpoints to the platform MSI controller.
> >
>
> I understand that MSI is broken on your hardware, but I was trying to
> understand 'why' specifically. Because, Root Port MSI capability doesn't have
> anything to do with the endpoint MSIs. And since you mentioned that this
> issue happens only on one platform, could be that the hardware designers
> have mistakenly wired the Root Port's 'MSI Enable' to iMSI-RX's enable signal
> or something similar?
Yes, that makes sense. Based on the behavior we're seeing, it does appear to
be a hardware wiring issue specific to these platforms, possibly with the Root
Port's MSI Enable incorrectly connected to the iMSI-RX enable signal.
>
> If so, we can introduce a flag 'dw_pcie_rp::keep_rp_msi_en' or something
> similar, set it for affected SoCs and skip the capability removal in
> pcie-designware-host.c
Good idea! I'll implement this approach with the 'dw_pcie_rp::keep_rp_msi_en'
flag and skip the capability removal for affected SoCs in pcie-designware-host.c.
Thanks for the suggestion!
Best Regards
Richard Zhu
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 05/30] KVM: arm64: Extract stage-2 permission logic in user_mem_abort()
From: Anshuman Khandual @ 2026-03-31 3:30 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-6-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> Extract the logic that computes the stage-2 protections and checks for
> various permission faults (e.g., execution faults on non-cacheable
> memory) into a new helper function, kvm_s2_fault_compute_prot(). This
> helper also handles injecting atomic/exclusive faults back into the
> guest when necessary.
>
> This refactoring step separates the permission computation from the
> mapping logic, making the main fault handler flow clearer.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 163 +++++++++++++++++++++++--------------------
> 1 file changed, 87 insertions(+), 76 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1f2c2200ccd8d..d1ffdce18631a 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1809,6 +1809,89 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
> return 1;
> }
>
> +static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> +{
> + struct kvm *kvm = fault->vcpu->kvm;
> +
> + /*
> + * Check if this is non-struct page memory PFN, and cannot support
> + * CMOs. It could potentially be unsafe to access as cacheable.
> + */
> + if (fault->vm_flags & (VM_PFNMAP | VM_MIXEDMAP) && !pfn_is_map_memory(fault->pfn)) {
> + if (fault->is_vma_cacheable) {
> + /*
> + * Whilst the VMA owner expects cacheable mapping to this
> + * PFN, hardware also has to support the FWB and CACHE DIC
> + * features.
> + *
> + * ARM64 KVM relies on kernel VA mapping to the PFN to
> + * perform cache maintenance as the CMO instructions work on
> + * virtual addresses. VM_PFNMAP region are not necessarily
> + * mapped to a KVA and hence the presence of hardware features
> + * S2FWB and CACHE DIC are mandatory to avoid the need for
> + * cache maintenance.
> + */
> + if (!kvm_supports_cacheable_pfnmap())
> + return -EFAULT;
> + } else {
> + /*
> + * If the page was identified as device early by looking at
> + * the VMA flags, vma_pagesize is already representing the
> + * largest quantity we can map. If instead it was mapped
> + * via __kvm_faultin_pfn(), vma_pagesize is set to PAGE_SIZE
> + * and must not be upgraded.
> + *
> + * In both cases, we don't let transparent_hugepage_adjust()
> + * change things at the last minute.
> + */
> + fault->s2_force_noncacheable = true;
> + }
> + } else if (fault->logging_active && !fault->write_fault) {
> + /*
> + * Only actually map the page as writable if this was a write
> + * fault.
> + */
> + fault->writable = false;
> + }
> +
> + if (fault->exec_fault && fault->s2_force_noncacheable)
> + return -ENOEXEC;
> +
> + /*
> + * Guest performs atomic/exclusive operations on memory with unsupported
> + * attributes (e.g. ld64b/st64b on normal memory when no FEAT_LS64WB)
> + * and trigger the exception here. Since the memslot is valid, inject
> + * the fault back to the guest.
> + */
> + if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(fault->vcpu))) {
> + kvm_inject_dabt_excl_atomic(fault->vcpu, kvm_vcpu_get_hfar(fault->vcpu));
> + return 1;
> + }
> +
> + if (fault->nested)
> + adjust_nested_fault_perms(fault->nested, &fault->prot, &fault->writable);
> +
> + if (fault->writable)
> + fault->prot |= KVM_PGTABLE_PROT_W;
> +
> + if (fault->exec_fault)
> + fault->prot |= KVM_PGTABLE_PROT_X;
> +
> + if (fault->s2_force_noncacheable) {
> + if (fault->vfio_allow_any_uc)
> + fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> + else
> + fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> + } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> + fault->prot |= KVM_PGTABLE_PROT_X;
> + }
> +
> + if (fault->nested)
> + adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
> +
> + return 0;
> +}
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_s2_trans *nested,
> struct kvm_memory_slot *memslot, unsigned long hva,
> @@ -1863,68 +1946,14 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>
> ret = 0;
>
> - /*
> - * Check if this is non-struct page memory PFN, and cannot support
> - * CMOs. It could potentially be unsafe to access as cacheable.
> - */
> - if (fault->vm_flags & (VM_PFNMAP | VM_MIXEDMAP) && !pfn_is_map_memory(fault->pfn)) {
> - if (fault->is_vma_cacheable) {
> - /*
> - * Whilst the VMA owner expects cacheable mapping to this
> - * PFN, hardware also has to support the FWB and CACHE DIC
> - * features.
> - *
> - * ARM64 KVM relies on kernel VA mapping to the PFN to
> - * perform cache maintenance as the CMO instructions work on
> - * virtual addresses. VM_PFNMAP region are not necessarily
> - * mapped to a KVA and hence the presence of hardware features
> - * S2FWB and CACHE DIC are mandatory to avoid the need for
> - * cache maintenance.
> - */
> - if (!kvm_supports_cacheable_pfnmap())
> - ret = -EFAULT;
> - } else {
> - /*
> - * If the page was identified as device early by looking at
> - * the VMA flags, fault->vma_pagesize is already representing the
> - * largest quantity we can map. If instead it was mapped
> - * via __kvm_faultin_pfn(), fault->vma_pagesize is set to PAGE_SIZE
> - * and must not be upgraded.
> - *
> - * In both cases, we don't let transparent_hugepage_adjust()
> - * change things at the last minute.
> - */
> - fault->s2_force_noncacheable = true;
> - }
> - } else if (fault->logging_active && !fault->write_fault) {
> - /*
> - * Only actually map the page as fault->writable if this was a write
> - * fault.
> - */
> - fault->writable = false;
> + ret = kvm_s2_fault_compute_prot(fault);
> + if (ret == 1) {
> + ret = 1; /* fault injected */
> + goto out_put_page;
> }
> -
> - if (fault->exec_fault && fault->s2_force_noncacheable)
> - ret = -ENOEXEC;
> -
> if (ret)
> goto out_put_page;
>
> - /*
> - * Guest performs atomic/exclusive operations on memory with unsupported
> - * attributes (e.g. ld64b/st64b on normal memory when no FEAT_LS64WB)
> - * and trigger the exception here. Since the fault->memslot is valid, inject
> - * the fault back to the guest.
> - */
> - if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(fault->vcpu))) {
> - kvm_inject_dabt_excl_atomic(fault->vcpu, kvm_vcpu_get_hfar(fault->vcpu));
> - ret = 1;
> - goto out_put_page;
> - }
> -
> - if (fault->nested)
> - adjust_nested_fault_perms(fault->nested, &fault->prot, &fault->writable);
> -
> kvm_fault_lock(kvm);
> pgt = fault->vcpu->arch.hw_mmu->pgt;
> if (mmu_invalidate_retry(kvm, fault->mmu_seq)) {
> @@ -1961,24 +1990,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> }
> }
>
> - if (fault->writable)
> - fault->prot |= KVM_PGTABLE_PROT_W;
> -
> - if (fault->exec_fault)
> - fault->prot |= KVM_PGTABLE_PROT_X;
> -
> - if (fault->s2_force_noncacheable) {
> - if (fault->vfio_allow_any_uc)
> - fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> - else
> - fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> - } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> - fault->prot |= KVM_PGTABLE_PROT_X;
> - }
> -
> - if (fault->nested)
> - adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
> -
> /*
> * Under the premise of getting a FSC_PERM fault, we just need to relax
> * permissions only if fault->vma_pagesize equals fault->fault_granule. Otherwise,
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 3:18 UTC (permalink / raw)
To: James Clark, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <ca1fe6ba-ec56-47a5-99ea-017dcc7a28ed@oss.qualcomm.com>
Hi James,
On 3/31/2026 9:29 AM, Jie Gan wrote:
>
> Hi James,
>
> On 3/30/2026 10:55 PM, James Clark wrote:
>>
>>
>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>> to userspace to support trace data parsing.
>>>
>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>> to the connected TPDA device.
>>>
>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>> ---
>>> Changes in v3:
>>> 1. Only allow user to read the traceid while the TPDM device is enabled.
>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>
>>> Changes in V2:
>>> 1. Use sysfs_emit instead of sprintf.
>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>> ---
>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++++
>>> + +++++++++-
>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/
>>> hwtracing/coresight/coresight-tpdm.c
>>> index da77bdaad0a4..c8339b973bfc 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>> *drvdata)
>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>> perf_event *event,
>>> enum cs_mode mode,
>>> - __maybe_unused struct coresight_path *path)
>>> + struct coresight_path *path)
>>> {
>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>> *csdev, struct perf_event *event,
>>> }
>>> __tpdm_enable(drvdata);
>>> + drvdata->traceid = path->trace_id;
>>> drvdata->enable = true;
>>> spin_unlock(&drvdata->spinlock);
>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>> .attrs = tpdm_attrs,
>>> };
>>> +static ssize_t traceid_show(struct device *dev,
>>> + struct device_attribute *attr, char *buf)
>>> +{
>>> + unsigned long val;
>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>> + return -EINVAL;
>>> +
>>> + val = drvdata->traceid;
>>
>> You probably need to take the coresight_mutex here otherwise you could
>> still return an invalid or stale value despite checking the mode.
>>
>
> Acked. I have missed this potential race condition.
>
>> There might also be some value in it returning the last used trace ID
>> even if the mode isn't enabled anymore. Because you can still read out
>> of the sink after disabling, so it makes more sense for a script to
>> read it at that point rather than when it's enabled. Also, you
>> probably don't want to be doing other things in your script in the
>> point between enabling and disabling.
>
> That's making sense. I shouldnt add such restriction for the read process.
>
I missed one point in last message.
Is that acceptable to export the coresight_mutex from the core module?
Currently, the coresight_mutex is used within the module only.
Thanks,
Jie
> Scenarios for reading:
> 1. device is enabled -> trace ID is valid
> 2. device is enabled then disabled -> trace ID is valid for the last
> trace event
> 3. device is never enabled -> invalid trace ID (value 0)
>
> we only need to check the validation of the trace ID.
>
> mutex_lock(&coresight_mutex);
> val = drvdata->traceid;
> mutex_unlock(&coresight_mutex);
>
> if (!val)
> return -EINVAL;
>
> return sysfs_emit(buf, "%#lx\n", val);
>
> Thanks,
> Jie
>
>>
>>> + return sysfs_emit(buf, "%#lx\n", val);
>>> +}
>>> +static DEVICE_ATTR_RO(traceid);
>>> +
>>> +static struct attribute *traceid_attrs[] = {
>>> + &dev_attr_traceid.attr,
>>> + NULL,
>>> +};
>>> +
>>> +static struct attribute_group traceid_attr_grp = {
>>> + .attrs = traceid_attrs,
>>> +};
>>> +
>>> static ssize_t dsb_mode_show(struct device *dev,
>>> struct device_attribute *attr,
>>> char *buf)
>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>> *tpdm_attr_grps[] = {
>>> &tpdm_cmb_patt_grp,
>>> &tpdm_cmb_msr_grp,
>>> &tpdm_mcmb_attr_grp,
>>> + &traceid_attr_grp,
>>> + NULL,
>>> +};
>>> +
>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>> + &traceid_attr_grp,
>>> NULL,
>>> };
>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>> struct resource *res)
>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>> if (res)
>>> desc.groups = tpdm_attr_grps;
>>> + else
>>> + desc.groups = static_tpdm_attr_grps;
>>> drvdata->csdev = coresight_register(&desc);
>>> if (IS_ERR(drvdata->csdev))
>>> return PTR_ERR(drvdata->csdev);
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/
>>> hwtracing/coresight/coresight-tpdm.h
>>> index 2867f3ab8186..11da64e1ade8 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>> * @cmb Specifics associated to TPDM CMB.
>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>> + * @traceid Trace ID of the path.
>>> */
>>> struct tpdm_drvdata {
>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>> struct cmb_dataset *cmb;
>>> u32 dsb_msr_num;
>>> u32 cmb_msr_num;
>>> + u8 traceid;
>>> };
>>> /* Enumerate members of various datasets */
>>>
>>> ---
>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>
>>> Best regards,
>>
>
^ permalink raw reply
* RE: [PATCH 1/1] arm: get task_stack reference before dump_backtrace
From: Maninder Singh @ 2026-03-31 2:59 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: bigeasy@linutronix.de, peterz@infradead.org, kees@kernel.org,
ardb@kernel.org, keithpac@amazon.com, linusw@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, mark.rutland@arm.com,
catalin.marinas@arm.com
In-Reply-To: <aa4Lo30Nq_t7qDqK@shell.armlinux.org.uk>
Hi,
> On Thu, Mar 05, 2026 at 12:35:27PM +0530, Maninder Singh wrote:
>> With Support of THREAD_INFO_IN_TASK, stack of task can be
>> freed earlier than task (even if task's reference is taken),
>> and it needs separate reference with try_get_task_stack()
>> before using the stack.
>> Otherwise if someone calls show_stack() for task, it can oops
>> the kernel like below: (Tried with normal race of show_stack when
>> task still exists, but its stack is freed)
>
> Looking at x86, it also has THREAD_INFO_IN_TASK, but I see nothing like
> this in show_stack(). How come x86 isn't similarly buggy?
>
Thanks for your inputs.
I sent patch for x86 also to report same issue, but no replies :)
https://lkml.org/lkml/2026/3/11/317
So I guess we will never know if it is buggy or not.
and why ARM64 has done the checkings and there is no need for x86 and ARM.
>> 8<--- cut here ---
>> Unable to handle kernel paging request at virtual address f8aebec4 when read
>> [f8aebec4] *pgd=83c2c811, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 7 [#1] SMP ARM
>> ..
>> CPU: 0 UID: 0 PID: 70 Comm: cat Not tainted 7.0.0-rc2-next-20260302+ #26 VOLUNTARY
>> ..
>> PC is at __read_once_word_nocheck+0x0/0x8
>> LR is at unwind_frame+0x6b0/0xa90
>> ...
>> Call trace:
>> __read_once_word_nocheck from unwind_frame+0x6b0/0xa90
>> unwind_frame from unwind_backtrace+0x178/0x1e0
>> unwind_backtrace from show_stack+0x10/0x14
>> ...
>>
>> ARM64 also takes care of it in dump_backtrace(), so same logic
>> is added for ARM also.
>>
>> Fixes: 18ed1c01a7dd ("ARM: smp: Enable THREAD_INFO_IN_TASK")
>> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Thanks,
Maninder Singh
^ permalink raw reply
* [PATCH 1/2] acpi: arm64: agdi: fix missing newline in error message
From: Haoyu Lu @ 2026-03-31 2:52 UTC (permalink / raw)
To: Rafael J . Wysocki, Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla,
Catalin Marinas, Will Deacon
Cc: Len Brown, Ilkka Koskinen, Russell King, linux-acpi,
linux-arm-kernel, linux-kernel, Haoyu Lu
Add the missing trailing newline to the dev_err() message
printed when SDEI event registration fails.
This keeps the error output as a properly terminated log line.
Fixes: a2a591fb76e6f5461dfd04715b69c317e50c43a5 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device")
Signed-off-by: Haoyu Lu <hechushiguitu666@gmail.com>
---
drivers/acpi/arm64/agdi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/agdi.c b/drivers/acpi/arm64/agdi.c
index feb4b2cb4618..0c2d9d6c160b 100644
--- a/drivers/acpi/arm64/agdi.c
+++ b/drivers/acpi/arm64/agdi.c
@@ -36,7 +36,7 @@ static int agdi_sdei_probe(struct platform_device *pdev,
err = sdei_event_register(adata->sdei_event, agdi_sdei_handler, pdev);
if (err) {
- dev_err(&pdev->dev, "Failed to register for SDEI event %d",
+ dev_err(&pdev->dev, "Failed to register for SDEI event %d\n",
adata->sdei_event);
return err;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/2] pwm: meson: Add support for Amlogic S7
From: Xianwei Zhao @ 2026-03-31 2:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic
In-Reply-To: <CAFBinCD-4dwp7pmM_GHK_N1kag_5VBZbP9VAwQOxcyg6aquj3w@mail.gmail.com>
Hi Martin,
Thanks for your review.
On 2026/3/31 05:44, Martin Blumenstingl wrote:
> Hi Xianwei Zhao,
>
> On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> Add support for Amlogic S7 PWM. Amlogic S7 different from the
>> previous SoCs, a controller includes one pwm, at the same time,
>> the controller has only one input clock source.
>>
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>> ---
>> drivers/pwm/pwm-meson.c | 32 ++++++++++++++++++++++++++++++--
>> 1 file changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
>> index 8c6bf3d49753..3d16694e254e 100644
>> --- a/drivers/pwm/pwm-meson.c
>> +++ b/drivers/pwm/pwm-meson.c
>> @@ -113,6 +113,7 @@ struct meson_pwm_data {
>> int (*channels_init)(struct pwm_chip *chip);
>> bool has_constant;
>> bool has_polarity;
>> + bool single_pwm;
> At first I wasn't sure about this and thought we should replace it
> with a num_pwms (or similar) variable.
> However, I think it will be hard to add a third (or even more)
> channels to the PWM controller (not just from driver perspective but
> also from hardware perspective). So I think this is good enough as the
> choice will only be 1 or 2.
> > [...]
This is not a third channel added here.
Compared with the previous controller having two channels, here the
control has only one channel. It's equivalent to the first channel
before, while the second channel is reserved.
>> +static const struct meson_pwm_data pwm_s7_data = {
>> + .channels_init = meson_pwm_init_channels_s7,
> I think you can use .channels_init = meson_pwm_init_channels_s4, if
> you change the code inside that function from:
> for (i = 0; i < MESON_NUM_PWMS; i++) {
> to:
> for (i = 0; i < chip->npwm; i++) {
>
> [...]
The method you suggested was exactly what I did in the first version,
but after my subsequent optimization, it's what you see now.
Since initialization only involves obtaining the clock, I modify the
code less in this way and the logic is also simpler.
>> @@ -650,9 +674,13 @@ static int meson_pwm_probe(struct platform_device *pdev)
>> {
>> struct pwm_chip *chip;
>> struct meson_pwm *meson;
>> + const struct meson_pwm_data *pdata = of_device_get_match_data(&pdev->dev);
>> int err;
>>
>> - chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
>> + if (pdata->single_pwm)
>> + chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*meson));
>> + else
>> + chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
> I don't think this code is too bad for now.
> However, I'm wondering if you want to make "channels" from struct
> meson_pwm a flexible array member in a future patch. In that case it
> will be helpful to have an "unsigned int npwm = pdata->single_pwm ? 1
> : MESON_NUM_PWMS;" (or similar) variable to future-proof your code.
> What do you think?
I considered this, but chose the current implementation. I will switch
to your suggestion in the next version.
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Peng Fan @ 2026-03-31 2:49 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <acqjS440STRl2sK2@p14s>
On Mon, Mar 30, 2026 at 10:22:35AM -0600, Mathieu Poirier wrote:
>On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> Cortex-M[7,33] processors use a fixed reset vector table format:
>>
>> 0x00 Initial SP value
>> 0x04 Reset vector
>> 0x08 NMI
>> 0x0C ...
>> ...
>> IRQ[n]
>>
>> In ELF images, the corresponding layout is:
>>
>> reset_vectors: --> hardware reset address
>> .word __stack_end__
>> .word Reset_Handler
>> .word NMI_Handler
>> .word HardFault_Handler
>> ...
>> .word UART_IRQHandler
>> .word SPI_IRQHandler
>> ...
>>
>> Reset_Handler: --> ELF entry point address
>> ...
>>
>> The hardware fetches the first two words from reset_vectors and populates
>> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
>> Reset_Handler.
>>
>> However, the ELF entry point does not always match the hardware reset
>> address. For example, on i.MX94 CM33S:
>>
>> ELF entry point: 0x0ffc211d
>> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>>
>
>But why? Why can't the ELF image be set to the right reset base?
Per zephyr general link script[1]:
ENTRY(CONFIG_KERNEL_ENTRY)
CONFIG_KERNEL_ENTRY(_start) is the first instruction that Cortex-M starts to
execute.
config KERNEL_ENTRY
string "Kernel entry symbol"
default "__start"
help
Code entry symbol, to be set at linking phase.
The hardware reset base is different: it is the address where the hardware
fetches the initial MSP and PC values from the vector table. Hardware uses
this base to initialize the stack pointer and program counter, and only then
does the Cortex‑M begin execution at the reset handler.
Aligning the ELF entry point with the hardware reset base on Cortex‑M systems
is possible, but it comes with several risks.
1, Semantic mismatch (ELF vs. hardware behavior)
2, Debuggers may attempt to set breakpoints or start execution at the entry symbol
[1] https://elixir.bootlin.com/zephyr/v4.4.0-rc1/source/include/zephyr/arch/arm/cortex_m/scripts/linker.ld#L103
Regards
Peng.
>
^ permalink raw reply
* Re: [PATCH v3] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Vincent Donnefort @ 2026-03-31 2:41 UTC (permalink / raw)
To: Sebastian Ene
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <20260330105441.3226904-1-sebastianene@google.com>
On Mon, Mar 30, 2026 at 10:54:41AM +0000, Sebastian Ene wrote:
> The ARM Service Calling Convention (SMCCC) specifies that the function
> identifier and parameters should be passed in registers, leaving the
> 16-bit immediate field un-handled in pKVM when an SMC instruction is
> trapped.
> Since the HVC is a private interface between EL2 and the host,
> enforce the host kernel running under pKVM to use an immediate value
> of 0 only when using SMCs to make it clear for non-compliant software
> talking to Trustzone that we only use SMCCC.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> ---
> v2 -> current:
> - move the ESR decoding of the imm16 in the handle_host_smc where it
> was supposed to be
> - updated the commit message to include the reason behind while we are
> not doing for HVCs as well
> - updated the commit message to clarify that pKVM is not handling the
> imm16
>
> v1 -> v2:
> - Dropped injecting an UNDEF and return an error instead
> (SMCCC_RET_NOT_SUPPORTED)
> - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> - Updated the title of the commit message from:
> "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> smc with imm16 != 0"
>
> Link to v2:
> https://lore.kernel.org/all/20260325113138.4171430-1-sebastianene@google.com/
> Link to v1:
> https://lore.kernel.org/all/20260324135728.3532400-1-sebastianene@google.com/
>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index e7790097db93..461cf5cb5ac7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -676,8 +676,14 @@ static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
> static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> + u64 esr = read_sysreg_el2(SYS_ESR);
> bool handled;
>
> + if (esr & ESR_ELx_xVC_IMM_MASK) {
> + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> + goto exit_skip_instr;
> + }
> +
> func_id &= ~ARM_SMCCC_CALL_HINTS;
>
> handled = kvm_host_psci_handler(host_ctxt, func_id);
> @@ -686,6 +692,7 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> if (!handled)
> default_host_smc_handler(host_ctxt);
>
> +exit_skip_instr:
> /* SMC was trapped, move ELR past the current PC. */
> kvm_skip_host_instr();
> }
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ 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