* Re: [patch 04/18] loongarch/syscall: Use syscall_enter_from_user_mode_randomize_stack()
From: Philippe Mathieu-Daudé @ 2026-07-09 11:15 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Peter Zijlstra, Huacai Chen, loongarch, Michael Ellerman,
Shrikanth Hegde, linuxppc-dev, Kees Cook, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Sven Schnelle, linux-s390, x86,
Mark Rutland, Jinjie Ruan, Andy Lutomirski, Oleg Nesterov,
Richard Henderson, Russell King, Catalin Marinas, Guo Ren,
Geert Uytterhoeven, Thomas Bogendoerfer, Helge Deller,
Yoshinori Sato, Richard Weinberger, Chris Zankel,
linux-arm-kernel, linux-alpha, linux-csky, linux-m68k, linux-mips,
linux-parisc, linux-sh, linux-um, Arnd Bergmann, Vineet Gupta,
Will Deacon, Brian Cain, Michal Simek, Dinh Nguyen,
David S. Miller, Andreas Larsson, linux-snps-arc, linux-hexagon,
linux-openrisc, sparclinux, linux-arch, Michal Suchánek,
Jonathan Corbet, linux-doc
In-Reply-To: <20260707190253.865955911@kernel.org>
On 7/7/26 21:06, Thomas Gleixner wrote:
> syscall_enter_from_user_mode_randomize_stack() replaces
> syscall_enter_from_user_mode() and the subsequent invocation of
> add_random_kstack_offset().
>
> The advantage is that it applies the stack randomization right after
> enter_from_user_mode() and thereby avoids the overhead of get/put_cpu_var()
> as that code is invoked with interrupts disabled.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: loongarch@lists.linux.dev
> ---
> arch/loongarch/kernel/syscall.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [patch 03/18] entry: Provide [syscall_]enter_from_user_mode_randomize_stack()
From: Philippe Mathieu-Daudé @ 2026-07-09 11:15 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Peter Zijlstra, Michael Ellerman, Shrikanth Hegde, linuxppc-dev,
Kees Cook, Huacai Chen, loongarch, Paul Walmsley, Palmer Dabbelt,
linux-riscv, Sven Schnelle, linux-s390, x86, Mark Rutland,
Jinjie Ruan, Andy Lutomirski, Oleg Nesterov, Richard Henderson,
Russell King, Catalin Marinas, Guo Ren, Geert Uytterhoeven,
Thomas Bogendoerfer, Helge Deller, Yoshinori Sato,
Richard Weinberger, Chris Zankel, linux-arm-kernel, linux-alpha,
linux-csky, linux-m68k, linux-mips, linux-parisc, linux-sh,
linux-um, Arnd Bergmann, Vineet Gupta, Will Deacon, Brian Cain,
Michal Simek, Dinh Nguyen, David S. Miller, Andreas Larsson,
linux-snps-arc, linux-hexagon, linux-openrisc, sparclinux,
linux-arch, Michal Suchánek, Jonathan Corbet, linux-doc
In-Reply-To: <20260707190253.816918647@kernel.org>
On 7/7/26 21:06, Thomas Gleixner wrote:
> Randomizing the syscall stack can only happen after state is established
> via enter_from_user_mode() or syscall_enter_from_user_mode(). The earlier
> it happens the better.
>
> Provide two new macros to consolidate that:
>
> - enter_from_user_mode_randomize_stack()
> enter_from_user_mode();
> add_random_kstack_offset_irqsoff();
>
> - syscall_enter_from_user_mode_randomize_stack()
> enter_from_user_mode_randomize_stack();
> syscall_enter_from_user_mode_work();
>
> to reduce boiler plate code.
>
> Those are macros and not inline functions as the latter would limit the
> stack randomization scope to the inline function itself.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> ---
> include/linux/entry-common.h | 56 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v7 16/22] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Catalin Marinas @ 2026-07-09 11:13 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <yq5apl0xgy89.fsf@kernel.org>
On Wed, Jul 08, 2026 at 11:28:14PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
>
> > On Wed, Jul 01, 2026 at 11:19:20AM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >> index 97987f850a33..acf67c7064db 100644
> >> --- a/arch/arm64/mm/init.c
> >> +++ b/arch/arm64/mm/init.c
> >> @@ -338,10 +338,8 @@ void __init arch_mm_preinit(void)
> >> unsigned int flags = SWIOTLB_VERBOSE;
> >> bool swiotlb = max_pfn > PFN_DOWN(arm64_dma_phys_limit);
> >>
> >> - if (is_realm_world()) {
> >> + if (is_realm_world())
> >> swiotlb = true;
> >> - flags |= SWIOTLB_FORCE;
> >> - }
> >
> > For this part:
> >
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> >
> >> diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
> >> index e05dc7649366..f3fc28f352ba 100644
> >> --- a/kernel/dma/direct.h
> >> +++ b/kernel/dma/direct.h
> >> @@ -88,37 +88,40 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
> >> {
> >> dma_addr_t dma_addr;
> >>
> >> + /*
> >> + * For a device requiring unencrypted DMA, MMIO memory is treated
> >> + * as shared by default.
> >> + */
> >> + if (force_dma_unencrypted(dev) && (attrs & DMA_ATTR_MMIO))
> >> + attrs |= DMA_ATTR_CC_SHARED;
> >> +
> >> if (is_swiotlb_force_bounce(dev)) {
> >> - if (!(attrs & DMA_ATTR_CC_SHARED)) {
> >> - if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
> >> - return DMA_MAPPING_ERROR;
> >> + if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
> >> + return DMA_MAPPING_ERROR;
> >>
> >> - return swiotlb_map(dev, phys, size, dir, attrs);
> >> - }
> >> - } else if (attrs & DMA_ATTR_CC_SHARED) {
> >> - return DMA_MAPPING_ERROR;
> >> + return swiotlb_map(dev, phys, size, dir, attrs);
> >> }
> >>
> >> - if (attrs & DMA_ATTR_MMIO) {
> >> - dma_addr = phys;
> >> - if (unlikely(!dma_capable(dev, dma_addr, size, false, attrs)))
> >> - goto err_overflow;
> >> - } else if (attrs & DMA_ATTR_CC_SHARED) {
> >> + if (attrs & DMA_ATTR_CC_SHARED)
> >> dma_addr = phys_to_dma_unencrypted(dev, phys);
> >> + else
> >> + dma_addr = phys_to_dma_encrypted(dev, phys);
> >
> > For AMD/SME, on host with memory encryption we now end up setting the C
> > bit for DMA_ATTR_MMIO. This is fine for RAM but not sure whether
> > some other MMIO bus understands this attribute. Maybe we should stick to
> > something like __phys_to_dma() for the !CC_SHARED && MMIO path. Or,
> > since this is not universally defined, just use the old dma_addr = phys
> > if MMIO and ignore any unlikely DMA offsets.
> >
>
> Considering for AMD/SME system an unencrypted dma addr is one without C
> bit, will this be good?
>
> /*
> * For host memory encryption and device requiring unencrypted DMA,
> * MMIO memory is treated as shared by default.
> */
> if (attrs & DMA_ATTR_MMIO) {
> if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) || force_dma_unencrypted(dev))
> attrs |= DMA_ATTR_CC_SHARED;
> }
Yes, I think it does the trick, preserves the current semantics for AMD.
I guess you could use a single 'if' for all checks (up to you).
--
Catalin
^ permalink raw reply
* Re: [patch 01/18] powerpc: Move stack randomization after syscall_enter_from_user_mode()
From: Philippe Mathieu-Daudé @ 2026-07-09 11:12 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Peter Zijlstra, Michael Ellerman, Shrikanth Hegde, linuxppc-dev,
Kees Cook, Huacai Chen, loongarch, Paul Walmsley, Palmer Dabbelt,
linux-riscv, Sven Schnelle, linux-s390, x86, Mark Rutland,
Jinjie Ruan, Andy Lutomirski, Oleg Nesterov, Richard Henderson,
Russell King, Catalin Marinas, Guo Ren, Geert Uytterhoeven,
Thomas Bogendoerfer, Helge Deller, Yoshinori Sato,
Richard Weinberger, Chris Zankel, linux-arm-kernel, linux-alpha,
linux-csky, linux-m68k, linux-mips, linux-parisc, linux-sh,
linux-um, Arnd Bergmann, Vineet Gupta, Will Deacon, Brian Cain,
Michal Simek, Dinh Nguyen, David S. Miller, Andreas Larsson,
linux-snps-arc, linux-hexagon, linux-openrisc, sparclinux,
linux-arch, Michal Suchánek, Jonathan Corbet, linux-doc
In-Reply-To: <20260707190253.718191130@kernel.org>
On 7/7/26 21:05, Thomas Gleixner wrote:
> add_random_kstack_offset() is invoked before syscall_enter_from_user_mode()
> establishes state. That's wrong because add_random_kstack_offset() calls
> into instrumentable code.
>
> Move it after syscall_enter_from_user_mode() to ensure that state is
> correctly established.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/kernel/syscall.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/arch/powerpc/kernel/syscall.c
> +++ b/arch/powerpc/kernel/syscall.c
> @@ -19,8 +19,8 @@ notrace long system_call_exception(struc
> long ret;
> syscall_fn f;
>
> - add_random_kstack_offset();
> r0 = syscall_enter_from_user_mode(regs, r0);
> + add_random_kstack_offset();
>
> if (unlikely(r0 >= NR_syscalls)) {
> if (unlikely(trap_is_unsupported_scv(regs))) {
>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] umh, treewide: Explicitly include linux/umh.h where needed
From: Petr Pavlu @ 2026-07-09 9:49 UTC (permalink / raw)
To: Michal Koutný
Cc: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Pavel Machek, Len Brown, Andrew Morton, Danilo Krummrich,
Nikolay Aleksandrov, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Howells,
Jarkko Sakkinen, Paul Moore, James Morris, Serge E. Hallyn,
Kentaro Takeda, Tetsuo Handa, linux-edac, linux-kernel, drbd-dev,
linux-block, greybus-dev, linuxppc-dev, linux-acpi, linux-fbdev,
dri-devel, linux-fsdevel, linux-nfs, ocfs2-devel, cgroups,
linux-modules, linux-pm, driver-core, bridge, netdev, keyrings,
linux-security-module
In-Reply-To: <ak6STbqZd-Q-c56v@localhost.localdomain>
On 7/8/26 8:13 PM, Michal Koutný wrote:
> Hi Petr.
>
> On Wed, Jul 08, 2026 at 05:44:29PM +0200, Petr Pavlu <petr.pavlu@suse.com> wrote:
>> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
>> index a4337c9b5287..60eb994c32ae 100644
>> --- a/kernel/cgroup/cgroup-v1.c
>> +++ b/kernel/cgroup/cgroup-v1.c
>> @@ -16,6 +16,7 @@
>> #include <linux/pid_namespace.h>
>> #include <linux/cgroupstats.h>
>> #include <linux/fs_parser.h>
>> +#include <linux/umh.h>
>>
>> #include <trace/events/cgroup.h>
>
> There is kmod.h in here too but it's unnecessary, no module lazy loading
> in this code.
You're right. I'll remove the kmod.h include from
kernel/cgroup/cgroup-v1.c. I went through all the files again and it
seems this was the only place I missed.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Set irqfd->producer only on success
From: Amit Machhiwal @ 2026-07-09 9:39 UTC (permalink / raw)
To: leixiang
Cc: seanjc, pbonzini, stable, Madhavan Srinivasan, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Suresh Warrier,
Paul Mackerras, linuxppc-dev, kvm, linux-kernel
In-Reply-To: <20260709055755.31297-1-leixiang@kylinos.cn>
On 2026/07/09 01:57 PM, leixiang wrote:
> Set irqfd->producer only after kvmppc_set_passthru_irq() succeeds to
> avoid leaving a dangling pointer on failure. The bypass manager does
> not register a failed producer, so the pointer is never cleared.
>
> Fixes: c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass")
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: leixiang <leixiang@kylinos.cn>
> ---
> arch/powerpc/kvm/book3s_hv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 61dbeea317f3..ff7b25629125 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6111,12 +6111,12 @@ static int kvmppc_irq_bypass_add_producer_hv(struct irq_bypass_consumer *cons,
> struct kvm_kernel_irqfd *irqfd =
> container_of(cons, struct kvm_kernel_irqfd, consumer);
>
> - irqfd->producer = prod;
> -
> ret = kvmppc_set_passthru_irq(irqfd->kvm, prod->irq, irqfd->gsi);
> if (ret)
> pr_info("kvmppc_set_passthru_irq (irq %d, gsi %d) fails: %d\n",
> prod->irq, irqfd->gsi, ret);
> + else
> + irqfd->producer = prod;
cons->add_producer is invoked by __connect() in virt/lib/irqbypass.c,
which itself is called from either irq_bypass_register_consumer() or
irq_bypass_register_producer(). __connect() only records the pairing —
setting cons->producer and prod->consumer — if add_producer returns 0.
static int __connect(struct irq_bypass_producer *prod,
struct irq_bypass_consumer *cons)
{
[...]
if (!ret) {
prod->consumer = cons;
cons->producer = prod;
}
On failure, no pairing is recorded, so __disconnect() is never called,
and del_producer is never invoked to clear irqfd->producer. The old
unconditional assignment indeed left a dangling pointer on any
kvmppc_set_passthru_irq() failure.
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
~Amit
>
> return ret;
> }
> --
> 2.45.0
^ permalink raw reply
* [PATCH v4 2/2] powerpc: enable to run posix cpu timers in task context
From: Vishal Chourasia @ 2026-07-09 9:21 UTC (permalink / raw)
To: maddy
Cc: peterz, frederic, npiggin, mpe, chleroy, sshegde, amachhiw,
vaibhav, harshpb, gautam, linuxppc-dev, kvm, linux-kernel,
Vishal Chourasia
In-Reply-To: <20260709092140.1753715-2-vishalc@linux.ibm.com>
From: Shrikanth Hegde <sshegde@linux.ibm.com>
Now that all kvm entry to guest paths handle the task work
using the generic framework, enable HAVE_POSIX_CPU_TIMERS_TASK_WORK
which allows running posix cpu timers in task context instead of running
them in hardirq. This would is a necessary step towards enabling
PREEMPT_RT on powerNV systems.
Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Signed-off-by: Vishal Chourasia <vishalc@linux.ibm.com>
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index f7ce5fff81f0..51555a0b1a26 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -281,6 +281,7 @@ config PPC
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
select HAVE_PREEMPT_DYNAMIC_KEY
+ select HAVE_POSIX_CPU_TIMERS_TASK_WORK
select HAVE_RETHOOK if KPROBES
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RELIABLE_STACKTRACE
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/2] KVM: powerpc: Use generic xfer to guest work function
From: Vishal Chourasia @ 2026-07-09 9:21 UTC (permalink / raw)
To: maddy
Cc: peterz, frederic, npiggin, mpe, chleroy, sshegde, amachhiw,
vaibhav, harshpb, gautam, linuxppc-dev, kvm, linux-kernel,
Vishal Chourasia
In-Reply-To: <20260709092140.1753715-2-vishalc@linux.ibm.com>
Since commit 2cd571245b43 ("sched/fair: Add related data structure for
task based throttle") in v6.18, CFS bandwidth throttling no longer
dequeues a task directly; it queues task_work via TWA_RESUME and sets
TIF_NOTIFY_RESUME, relying on that work running before the task returns
to guest/user mode. The powerpc KVM run loops only checked for reschedule
and signals, never TIF_NOTIFY_RESUME, so the deferred throttle never ran
while a vCPU stayed in the run loop: a CPU-bound guest that rarely exits
to userspace ran far past its cpu.max quota and then appeared frozen for
minutes while the accrued throttle debt was repaid.
Use the generic infrastructure to check for and handle pending work
before transitioning into guest mode, replacing the open-coded
need_resched() and cond_resched() checks in the Book3S HV run loops and
in the common kvmppc_prepare_to_enter() used by the Book3S PR and BookE
run loops. The redundant signal_pending() recheck (and its sigpend label)
in kvmhv_run_single_vcpu() is also dropped, as
xfer_to_guest_mode_work_pending() is a superset of it.
This picks up handling for TIF_NOTIFY_RESUME, which was previously
ignored, meaning task work will now be correctly handled on every
guest re-entry.
Selecting VIRT_XFER_TO_GUEST_WORK disables RCU's last-resort self-IPI
fallback for vCPU tasks (see rcu_irq_work_resched()), which on
nohz_full CPUs was what forced a reschedule for deferred rcuog wakeups
queued right before guest entry. Take over that obligation the same way
x86 and s390 do: call xfer_to_guest_mode_prepare() with IRQs disabled
immediately before the final xfer_to_guest_mode_work_pending() check at
each guest-entry gate (kvmhv_run_single_vcpu(), kvmppc_run_core() and
kvmppc_prepare_to_enter()).
In kvmppc_prepare_to_enter(), IRQs are now disabled with
local_irq_disable() before hard_irq_disable(): on 32-bit,
hard_irq_disable() is a raw MSR[EE] clear that bypasses the
lockdep/irq-tracing state, and the strict xfer_to_guest_mode helpers
assert that IRQs are seen as disabled. This also allows upgrading the
racy __xfer_to_guest_mode_work_pending() check to the asserting
variant, as this loop is the terminal gate for the PR and BookE paths.
In kvmhv_run_single_vcpu(), the -EINTR exit and the pre-existing
kvmhv_setup_mmu() failure exit now leave via the done label instead of
returning directly, keeping the run_vcpu enter/exit tracepoints
balanced and vcpu->arch.ret consistent with the returned value.
In kvmppc_prepare_to_enter() the generic helper accounts the signal exit
(vcpu->stat.signal_exits and KVM_EXIT_INTR) but does not set the exit
type, so kvmppc_set_exit_type(SIGNAL_EXITS) is retained on the signal
path to preserve the E500 CONFIG_KVM_EXIT_TIMING histogram; it is a no-op
otherwise.
Signed-off-by: Vishal Chourasia <vishalc@linux.ibm.com>
---
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/book3s_hv.c | 39 +++++++++++++++++++++++-------------
arch/powerpc/kvm/booke.c | 1 +
arch/powerpc/kvm/powerpc.c | 37 +++++++++++++++++++++++++---------
4 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 9a0d1c1aca6c..b6bc2fc86dca 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -22,6 +22,7 @@ config KVM
select KVM_COMMON
select KVM_VFIO
select HAVE_KVM_IRQ_BYPASS
+ select VIRT_XFER_TO_GUEST_WORK
config KVM_BOOK3S_HANDLER
bool
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 61dbeea317f3..3cfe9a7be9c6 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3853,7 +3853,8 @@ static noinline void kvmppc_run_core(struct kvmppc_vcore *vc)
*/
local_irq_disable();
hard_irq_disable();
- if (lazy_irq_pending() || need_resched() ||
+ xfer_to_guest_mode_prepare();
+ if (lazy_irq_pending() || xfer_to_guest_mode_work_pending() ||
recheck_signals_and_mmu(&core_info)) {
local_irq_enable();
vc->vcore_state = VCORE_INACTIVE;
@@ -4824,10 +4825,16 @@ static int kvmppc_run_vcpu(struct kvm_vcpu *vcpu)
vc->runner = vcpu;
if (n_ceded == vc->n_runnable) {
kvmppc_vcore_blocked(vc);
- } else if (need_resched()) {
+ } else if (__xfer_to_guest_mode_work_pending()) {
kvmppc_vcore_preempt(vc);
- /* Let something else run */
- cond_resched_lock(&vc->lock);
+ /*
+ * Let something else run. The raw helper is used as
+ * signal exits are accounted by this path already;
+ * it may schedule(), so drop the vcore lock.
+ */
+ spin_unlock(&vc->lock);
+ xfer_to_guest_mode_handle_work();
+ spin_lock(&vc->lock);
if (vc->vcore_state == VCORE_PREEMPT)
kvmppc_vcore_end_preempt(vc);
} else {
@@ -4895,12 +4902,16 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
run->exit_reason = KVM_EXIT_FAIL_ENTRY;
run->fail_entry.hardware_entry_failure_reason = 0;
vcpu->arch.ret = r;
- return r;
+ goto done;
}
}
- if (need_resched())
- cond_resched();
+ r = kvm_xfer_to_guest_mode_handle_work(vcpu);
+ if (r) {
+ /* -EINTR: signal pending, exit to userspace (KVM_EXIT_INTR) */
+ vcpu->arch.ret = r;
+ goto done;
+ }
kvmppc_update_vpas(vcpu);
@@ -4914,9 +4925,13 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
vcpu->arch.state = KVMPPC_VCPU_RUNNABLE;
- if (signal_pending(current))
- goto sigpend;
- if (need_resched() || !kvm->arch.mmu_ready)
+ xfer_to_guest_mode_prepare();
+
+ /*
+ * IRQs are disabled here, so on pending work bail to the outer loop,
+ * which handles it via kvm_xfer_to_guest_mode_handle_work() above.
+ */
+ if (xfer_to_guest_mode_work_pending() || !kvm->arch.mmu_ready)
goto out;
vcpu->cpu = pcpu;
@@ -5068,10 +5083,6 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
return vcpu->arch.ret;
- sigpend:
- vcpu->stat.signal_exits++;
- run->exit_reason = KVM_EXIT_INTR;
- vcpu->arch.ret = -EINTR;
out:
vcpu->cpu = -1;
vcpu->arch.thread_cpu = -1;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index f3ddb24ece74..5fba199dfdd6 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -722,6 +722,7 @@ int kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
if (vcpu->arch.shared->msr & MSR_WE) {
local_irq_enable();
kvm_vcpu_halt(vcpu);
+ local_irq_disable();
hard_irq_disable();
kvmppc_set_exit_type(vcpu, EMULATED_MTMSRWE_EXITS);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 00302399fc37..be5e48ae0c6c 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -81,23 +81,41 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
int r;
WARN_ON(irqs_disabled());
+ /*
+ * local_irq_disable() first: on 32-bit, hard_irq_disable() alone is a
+ * raw MSR[EE] clear that bypasses the lockdep/irq-tracing state, and
+ * the xfer_to_guest_mode helpers assert IRQs are seen as disabled.
+ */
+ local_irq_disable();
hard_irq_disable();
while (true) {
- if (need_resched()) {
+ xfer_to_guest_mode_prepare();
+
+ if (xfer_to_guest_mode_work_pending()) {
+ /*
+ * The helper must run with IRQs enabled and may
+ * schedule(). On a pending signal it returns -EINTR
+ * with run->exit_reason and vcpu->stat.signal_exits
+ * already set, so just return to userspace.
+ */
local_irq_enable();
- cond_resched();
+ r = kvm_xfer_to_guest_mode_handle_work(vcpu);
+ local_irq_disable();
hard_irq_disable();
+ if (r) {
+ /*
+ * The generic helper does not set the exit
+ * type; record it for the E500
+ * CONFIG_KVM_EXIT_TIMING histogram (a no-op
+ * otherwise).
+ */
+ kvmppc_set_exit_type(vcpu, SIGNAL_EXITS);
+ break;
+ }
continue;
}
- if (signal_pending(current)) {
- kvmppc_account_exit(vcpu, SIGNAL_EXITS);
- vcpu->run->exit_reason = KVM_EXIT_INTR;
- r = -EINTR;
- break;
- }
-
vcpu->mode = IN_GUEST_MODE;
/*
@@ -116,6 +134,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
local_irq_enable();
trace_kvm_check_requests(vcpu);
r = kvmppc_core_check_requests(vcpu);
+ local_irq_disable();
hard_irq_disable();
if (r > 0)
continue;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/2] KVM: powerpc: Use generic xfer to guest work function
From: Vishal Chourasia @ 2026-07-09 9:21 UTC (permalink / raw)
To: maddy
Cc: peterz, frederic, npiggin, mpe, chleroy, sshegde, amachhiw,
vaibhav, harshpb, gautam, linuxppc-dev, kvm, linux-kernel,
Vishal Chourasia
This series fixes a KVM scheduling bug on Book3S HV where a guest VM
under a cpu.max bandwidth limit can run arbitrarily past its quota and
then appear frozen for minutes afterwards.
== Problem ==
Since commit 2cd571245b43 ("sched/fair: Add related data structure for
task based throttle"), merged in v6.18, CFS bandwidth throttling no
longer dequeues a task directly. Instead it queues a task_work item via
task_work_add(..., TWA_RESUME), sets TIF_NOTIFY_RESUME, and relies on
that work running on the return path to actually dequeue the task.
The powerpc KVM run loops only test TIF_SIGPENDING and TIF_NEED_RESCHED
before re-entering the guest; TIF_NOTIFY_RESUME is never checked. For a
CPU-bound guest that generates few KVM exits back to userspace, the vCPU
thread never returns to user mode, so the deferred throttle task_work
never runs. The guest keeps running unchecked while its
runtime_remaining goes increasingly negative, and once it finally does
exit to userspace it is legitimately throttled for minutes while the
accrued debt is repaid at the bandwidth-timer replenishment rate.
The generic xfer-to-guest-mode infrastructure (commit 935ace2fb5cc,
"entry: Provide infrastructure for work before transitioning to guest
mode") exists precisely to handle this kind of work before each guest
entry. A full trace-backed root-cause analysis was posted with v1 [2].
== Fix ==
Opt powerpc KVM into VIRT_XFER_TO_GUEST_WORK and use the generic
xfer_to_guest_mode helpers to check for and handle pending guest-mode
work (reschedule, signals, and TIF_NOTIFY_RESUME task_work such as the
deferred CFS throttle) on every guest re-entry:
- Book3S HV: both run loops — kvmhv_run_single_vcpu() for POWER9+ and
kvmppc_run_vcpu() for pre-POWER9.
- Book3S PR and BookE: the common kvmppc_prepare_to_enter(), which
likewise only checked need_resched()/signal_pending().
== Changes from v3 ==
- BookE: add local_irq_disable() before hard_irq_disable() on the emulated
MTMSR[WE] path so lockdep's irq-tracing state is resynced, fixing a
lockdep_assert_irqs_disabled() splat in the following
xfer_to_guest_mode_prepare(). (Reported by Sashiko AI review)
== Changes from v2 ==
- Add xfer_to_guest_mode_prepare() check for pending rcuog wakeup before
entering guest
- While at it patch all exit points for kvmhv_run_single_vcpu() via
done label matching the corresponding trace_kvmppc_run_vcpu_enter()
with trace_kvmppc_run_vcpu_exit() tracepoint. (Reported by Sashiko AI
review)
- Include posix cpu timer enablement patch by Shrikanth as part of this
series
== Changes from v1 ==
- Extend the fix beyond Book3S HV to the shared powerpc KVM entry path:
also convert the common kvmppc_prepare_to_enter() used by Book3S PR
and BookE. (Shrikanth Hegde)
- Move "select VIRT_XFER_TO_GUEST_WORK" from KVM_BOOK3S_64_HV up to the
common "config KVM" so every powerpc KVM variant gets the
infrastructure.
- Drop the redundant signal_pending() recheck and its sigpend label in
kvmhv_run_single_vcpu(); xfer_to_guest_mode_work_pending() is a
superset of it.
- Preserve the E500 CONFIG_KVM_EXIT_TIMING histogram on the signal path
via an explicit kvmppc_set_exit_type(SIGNAL_EXITS).
[1] https://lore.kernel.org/all/20250421102837.78515-2-sshegde@linux.ibm.com/
[2] https://lore.kernel.org/all/20260626105449.2897924-2-vishalc@linux.ibm.com/
Shrikanth Hegde (1):
powerpc: enable to run posix cpu timers in task context
Vishal Chourasia (1):
KVM: powerpc: Use generic xfer to guest work function
arch/powerpc/Kconfig | 1 +
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/book3s_hv.c | 39 +++++++++++++++++++++++-------------
arch/powerpc/kvm/booke.c | 1 +
arch/powerpc/kvm/powerpc.c | 37 +++++++++++++++++++++++++---------
5 files changed, 56 insertions(+), 23 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH] KVM: Use vma_lookup() in kvm_host_page_size()
From: Ritesh Harjani @ 2026-07-09 8:46 UTC (permalink / raw)
To: David Woodhouse, Paolo Bonzini
Cc: kvm, linux-kernel, Madhavan Srinivasan, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), linuxppc-dev
In-Reply-To: <71775f561c4b7fb23b7af0725c6ce232a4b27b20.camel@infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> kvm_host_page_size() uses find_vma() to determine the host page size
> backing a guest page. find_vma() returns the next VMA when the address
> falls in an unmapped hole, which means an unmapped address inherits the
> page size of a completely unrelated VMA at a higher address. This is
> never a meaningful result.
>
> Replace find_vma() with vma_lookup() so that a hole address returns
> NULL, causing the function to return PAGE_SIZE (the safe default)
> rather than an unrelated VMA's page size.
>
That's exactly right.
> This is currently only cosmetic, as the only caller is in PPC book3s
> support (kvmppc_xive_native_set_queue_config()) and subsequently returns
> failure if !gfn_to_page() anyway.
>
Yup. The change make sense to me. Feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> virt/kvm/kvm_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 89489996fbc1..d33761123459 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2693,7 +2693,7 @@ unsigned long kvm_host_page_size(struct kvm_vcpu *vcpu, gfn_t gfn)
> return PAGE_SIZE;
>
> mmap_read_lock(current->mm);
> - vma = find_vma(current->mm, addr);
> + vma = vma_lookup(current->mm, addr);
> if (!vma)
> goto out;
>
> --
> 2.43.0
^ permalink raw reply
* Re: [patch 12/18] ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()
From: Geert Uytterhoeven @ 2026-07-09 8:41 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Peter Zijlstra, Arnd Bergmann, Oleg Nesterov,
Richard Henderson, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Guo Ren, Brian Cain, Michal Simek,
Thomas Bogendoerfer, Dinh Nguyen, Helge Deller, Yoshinori Sato,
David S. Miller, Andreas Larsson, Chris Zankel, linux-alpha,
linux-snps-arc, linux-arm-kernel, linux-csky, linux-hexagon,
linux-m68k, linux-mips, linux-openrisc, linux-parisc, linux-sh,
sparclinux, linux-um, linux-arch, Michael Ellerman,
Shrikanth Hegde, linuxppc-dev, Kees Cook, Huacai Chen, loongarch,
Paul Walmsley, Palmer Dabbelt, linux-riscv, Sven Schnelle,
linux-s390, x86, Mark Rutland, Jinjie Ruan, Andy Lutomirski,
Richard Weinberger, Michal Suchánek, Jonathan Corbet,
linux-doc
In-Reply-To: <20260707190254.280015701@kernel.org>
On Tue, 7 Jul 2026 at 21:06, Thomas Gleixner <tglx@kernel.org> wrote:
> The return value of that function is boolean and tells the caller whether
> to permit the syscall processing or not.
>
> Rename the function so the purpose is clear and make the return type bool.
> arch/m68k/kernel/ptrace.c | 2 +-
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
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: [RFC PATCH 0/6] selftests/vfio: Add sPAPR TCE v2 coverage
From: Narayana Murty N @ 2026-07-09 8:49 UTC (permalink / raw)
To: David Matlack
Cc: alex, shuah, amastro, rananta, kvm, linux-kselftest, linux-kernel,
vaibhav, sbhat, harshpb, linuxppc-dev
In-Reply-To: <akwyZvbv7Fg8mfB2@google.com>
Hi David,
Thank you for your detailed review comments on this series.
On 07/07/26 4:25 AM, David Matlack wrote:
> On 2026-07-02 11:28 PM, Narayana Murty N wrote:
>> This RFC adds PowerPC sPAPR TCE v2 support to VFIO selftests.
> nit: Please use "vfio: selftests: ..." for commit shortlogs.
Agree, will fix all commit shortlogs in v2.
>
>> The series adds a selftest IOMMU mode for the legacy VFIO container
>> backend, adds helpers for default and dynamic DMA windows, and exercises
>> the sPAPR DDW path through the DMA mapping tests.
> Thanks for sending. Is there anyway I could run these tests on PowerPC,
> e.g. with QEMU, to try things out? I don't have access to any hardware.
I had tested this patch series on real power h/w (pseries and powernv).
However I am not sure if the required firmware support is implemented in
QEMU.
I will check and get back on this.
>> sPAPR TCE v2 remains a legacy VFIO container backend. This series does
>> not add iommufd or VFIO cdev support for sPAPR.
>>
>> The main points are
>> 1. add VFIO_SELFTESTS_IOMMU_MODE for selecting a backend
>> 2. add vfio_spapr_tce_v2_iommu as the PowerPC VFIO backend
>> 3. preserve the platform default DMA window
>> 4. create and tear down only selftest-created DDWs
>> 5. prepare the DMA window before IOVA allocation
>> 6. exercise DDW creation for hugepage DMA mappings
>> 7. accept sPAPR-specific errno for invalid DMA ranges
>>
>> Example:
>>
>> VFIO_SELFTESTS_IOMMU_MODE=vfio_spapr_tce_v2_iommu
>> ./vfio_dma_mapping_test <BDF>
>>
>> Observed coverage includes anonymous mappings through the default window
>> and 2MB hugetlb mappings through a DDW. 1GB hugetlb mappings may skip when
>> the platform rejects the requested DDW characteristics.
>>
>> Feedback is requested from the VFIO and PowerPC communities on:
>> 1. whether the sPAPR TCE v2 helpers should remain in the common VFIO
>> selftest library or move into a sPAPR-specific test helper?
> Responded in the patch. Let's move to their own file.
Will do. v2 will have:
lib/iommu_spapr.c — all sPAPR logic, compiled only on powerpc
lib/iommu_spapr_stub.c — empty stubs returning -EOPNOTSUPP,
compiled on all other architectures
lib/include/libvfio/iommu_spapr.h — declarations
iommu.c will call the sPAPR helpers unconditionally with no #ifdefs in
function bodies.
>> 2. whether DDW setup through hugepage mappings is the right initial
>> coverage?
> One thing I'm not sure is how much value you get out of exercising the
> DDW stuff through that test specifically. Would it make more sense to
> have a DDW-specific test so you can test all the edge cases you care
> about directly instead? Then vfio_dma_mapping_test can stay generic.
Agreed. For v2 I plan to introduce a dedicated vfio_spapr_ddw_test that
covers DDW creation, window selection, page-size negotiation, and
removal directly, and keep vfio_dma_mapping_test generic. The hugepage
variants in vfio_dma_mapping_test will then just exercise the mapping
path itself without being the primary DDW coverage vehicle.
>
> BTW, is that the only test that passes right now? What is the status of
> the other VFIO selftests on PowerPC after this series?
vfio_dma_mapping_test — anonymous and 2 MB hugetlb variants PASS;
vfio_dma_mapping_mmio_test — PASS (overflow test passes with -ENXIO
fix).
vfio_pci_device_test — PASS.
Below tests are not supported:
vfio_pci_driver_test
vfio_iommufd_setup_test
currently it fails unsupported tests when triggred via scripts/run.sh
I will start including test logs in cover letter starting with RFC V2.
>
>> 3. whether the sPAPR-specific overflow errno expectation should be
>> accepted, skipped, or hidden behind a backend helper?
> Responded in the patch. Let's keep the check but base it off IOMMU mode
> not __powerpc__. Also it'd be good to avoid duplicating the code with a
> helper function or macro but that's a small thing.
Agreed. Will replace the #ifdef __powerpc__ guard with a runtime check:
int expected = iommu_is_spapr(self->iommu) ? -ENXIO : -EOVERFLOW;
ASSERT_EQ(rc, expected);
I will add a helper to avoid code duplication.
>> 4. whether PowerPC should generate only the sPAPR TCE v2 fixture variants,
>> or keep the generic IOMMU-mode matrix and skip unsupported modes.
> For (4), I think skipping unsupported modes would be a good improvement.
> Even on x86 and ARM we would want that feature. e.g. It's possible for
> someone to run VFIO selftests on a kernel that has VFIO Type1 IOMMUs
> enabled but not IOMMUFD. Today that will cause all the tests to fail.
> But ideally it would wouldn't. Tests that just want the default IOMMU
> mode should use Type1, and tests that want to replicate across all IOMMU
> modes should skip the IOMMUFD variants. Same thing applies to the SPAPR
> IOMMU mode.
This is a great point and it also addresses the concern raised in the
Patch 1/6 review about forcing the user to set VFIO_SELFTESTS_IOMMU_MODE.
Once again thanks for the thorough review.
I shall address all the review comments on the series before sending v2.
Regards,
Narayana
>> TODO: vfio_spapr_tce_v1_iommu yet to be covered.
>>
>> Narayana Murty N (6):
>> selftests/vfio: allow selecting IOMMU backend from environment
>> selftests/vfio: add sPAPR TCE v2 IOMMU mode
>> selftests/vfio: add sPAPR TCE v2 DMA window helpers
>> selftests/vfio: Exercise sPAPR DDW path for hugepage DMA mappings
>> selftests/vfio: Accept sPAPR errno for DMA range overflow
>> selftests/vfio: Enable VFIO selftests on ppc64 and ppc64le
>>
>> .../selftests/vfio/lib/include/libvfio.h | 9 +
>> .../vfio/lib/include/libvfio/iommu.h | 26 ++
>> tools/testing/selftests/vfio/lib/iommu.c | 280 +++++++++++++++++-
>> tools/testing/selftests/vfio/lib/libvfio.c | 37 +++
>> .../selftests/vfio/vfio_dma_mapping_test.c | 30 ++
>> .../selftests/vfio/vfio_pci_device_test.c | 4 +-
>> tools/testing/selftests/vfio/Makefile | 2 +-
>> 7 files changed, 382 insertions(+), 6 deletions(-)
>>
>> --
>> 2.51.1
>>
^ permalink raw reply
* Re: [PATCH] KVM: Nullify irqfd->producer when add_producer() fails
From: leixiang @ 2026-07-09 5:45 UTC (permalink / raw)
To: Sean Christopherson
Cc: stable, Madhavan Srinivasan, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), Paolo Bonzini, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Paul Mackerras, Suresh Warrier, linuxppc-dev, kvm, linux-kernel,
leixiang
In-Reply-To: <ak59frQUBl9Gs3Qn@google.com>
On 7/9/26 00:40, Sean Christopherson wrote:
> On Mon, Jun 22, 2026, leixiang wrote:
>> The x86 and powerpc add_producer() callbacks set irqfd->producer before the
>> fallible setup and never clear it on error. The bypass manager doesn't
>> register a producer whose add_producer() failed -- producer->eventfd is
>> left NULL, so the later unregister early-returns and del_producer() is
>> never called -- so nothing ever drops the pointer.
>>
>> For VFIO PCI the producer is embedded in struct vfio_pci_irq_ctx and freed
>> when the vector is disabled, after which a routing update dereferences the
>> dangling pointer via kvm_arch_update_irqfd_routing().
>>
>> Nullify irqfd->producer on the error paths.
>>
>> Fixes: 77e1b8332d1d ("KVM: x86: Decouple device assignment from IRQ bypass")
>> Fixes: c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: leixiang <leixiang@kylinos.cn>
>
> Please post the PPC patch as a separate patch. x86 and PPC are separate maintainer
> domains and the backports will likely need to go to different LTS kernels.
>
> I'll grab/extract the x86 change from here (and I'll massage the changelog as
> appropriate).
Thank you for the review and guidance. I will submit a separate PPC patch.
>> ---
>> arch/powerpc/kvm/book3s_hv.c | 4 +++-
>> arch/x86/kvm/irq.c | 4 +++-
>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 61dbeea317f3..14919b76fb32 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -6114,9 +6114,11 @@ static int kvmppc_irq_bypass_add_producer_hv(struct irq_bypass_consumer *cons,
>> irqfd->producer = prod;
>>
>> ret = kvmppc_set_passthru_irq(irqfd->kvm, prod->irq, irqfd->gsi);
>> - if (ret)
>> + if (ret) {
>> pr_info("kvmppc_set_passthru_irq (irq %d, gsi %d) fails: %d\n",
>> prod->irq, irqfd->gsi, ret);
>> + irqfd->producer = NULL;
>> + }
>
> Unlike x86, AFAICT there's no need to set irqfd->producer before configuring
> the passthru/bypass stuff. So I think that fix could be this?
>
> diff --git arch/powerpc/kvm/book3s_hv.c arch/powerpc/kvm/book3s_hv.c
> index 61dbeea317f3..ff7b25629125 100644
> --- arch/powerpc/kvm/book3s_hv.c
> +++ arch/powerpc/kvm/book3s_hv.c
> @@ -6111,12 +6111,12 @@ static int kvmppc_irq_bypass_add_producer_hv(struct irq_bypass_consumer *cons,
> struct kvm_kernel_irqfd *irqfd =
> container_of(cons, struct kvm_kernel_irqfd, consumer);
>
> - irqfd->producer = prod;
> -
> ret = kvmppc_set_passthru_irq(irqfd->kvm, prod->irq, irqfd->gsi);
> if (ret)
> pr_info("kvmppc_set_passthru_irq (irq %d, gsi %d) fails: %d\n",
> prod->irq, irqfd->gsi, ret);
> + else
> + irqfd->producer = prod;
>
> return ret;
> }
Agreed. Your approach is cleaner.
^ permalink raw reply
* Re: [PATCH v2] powerpc/64s: Clarify copy_and_flush() cache sync loop comment
From: Mukesh Kumar Chaurasiya @ 2026-07-09 8:32 UTC (permalink / raw)
To: Nikhil Kumar Singh
Cc: linuxppc-dev, linux-kernel, maddy, mpe, npiggin, chleroy, adityag,
mahesh
In-Reply-To: <b5f97f5b-4a17-46f7-8830-a9c4c121f0c4@linux.ibm.com>
On Thu, Jul 09, 2026 at 11:40:44AM +0530, Nikhil Kumar Singh wrote:
> Hi Mukesh,
>
> Ideally, checkpatch should take care of this, I see no checkpatch errors.
>
> ```
> ./scripts/checkpatch.pl
> v2-0001-powerpc-64s-Clarify-copy_and_flush-cache-sync-loo.patch
> total: 0 errors, 0 warnings, 26 lines checked
>
> v2-0001-powerpc-64s-Clarify-copy_and_flush-cache-sync-loo.patch has no
> obvious style problems and is ready for submission.
> ```
>
> Thanks
> ~ Nikhil
>
I am saying it looks nicer and easy to read for everyone if they are
aligned. If you think it's not readable with the 80 char limit, put the
whole comment before the function start. That will also makes it a
little nicer. Right now it's getting wrapped around and it's difficult
to read.
Regards,
Mukesh
> On 07/07/26 12:48, Nikhil Kumar Singh wrote:
> > Hi Mukesh,
> >
> > Thanks for reviewing the patch and for the suggestion.
> > I'd prefer to keep the current alignment as I find it a bit more
> > readable.
> >
> > Thanks,
> > ~ Nikhil
> >
> > On 07/07/26 11:08, Mukesh Kumar Chaurasiya wrote:
> > > On Mon, Jul 06, 2026 at 01:57:08PM +0530, Nikhil Kumar Singh wrote:
> > > > The value loaded into r0 in copy_and_flush() represents the number of
> > > > 8-byte words processed between cache synchronization operations.
> > > >
> > > > The existing comment refers to cache line size, which can make
> > > > it appear
> > > > that the value is a cache line size in bytes rather than a loop count.
> > > > Clarify the comment to explain that the loop processes 8 words
> > > > (64 bytes)
> > > > per cache synchronization iteration, and that increasing the
> > > > value would
> > > > skip cache maintenance for intermediate cache lines.
> > > >
> > > > This is a comment-only change with no functional impact.
> > > >
> > > > Signed-off-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
> > > > ---
> > > > arch/powerpc/kernel/head_64.S | 20 ++++++++++++--------
> > > > 1 file changed, 12 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/powerpc/kernel/head_64.S
> > > > b/arch/powerpc/kernel/head_64.S
> > > > index 63432a33ec49..a54f6f979173 100644
> > > > --- a/arch/powerpc/kernel/head_64.S
> > > > +++ b/arch/powerpc/kernel/head_64.S
> > > > @@ -713,14 +713,18 @@ p_end: .8byte _end - copy_to_here
> > > > _GLOBAL(copy_and_flush)
> > > > addi r5,r5,-8
> > > > addi r6,r6,-8
> > > > -4: li r0,8 /* Use the smallest common */
> > > > - /* denominator cache line */
> > > > - /* size. This results in */
> > > > - /* extra cache line flushes */
> > > > - /* but operation is correct. */
> > > > - /* Can't get cache line size */
> > > > - /* from NACA as it is being */
> > > > - /* moved too. */
> > > > +4: li r0,8 /* r0 is the number of 8-byte words */
> > > > + /* to copy per cache sync iteration. */
> > > > + /* 8 words * 8 bytes = 64 bytes. 64B is */
> > > > + /* the current default cache line size. */
> > > > + /* This is a loop count, not a byte */
> > > > + /* count. Increasing it may skip */
> > > > + /* dcbst/icbi for lines in between and */
> > > > + /* leave stale instructions in icache. */
> > > > + /* This results in extra cache line */
> > > > + /* flushes but operation is correct. */
> > > > + /* Can't get cache line size from NACA */
> > > > + /* as it is being moved too. */
> > > The comment looks fine. But the alignement of the comment is still
> > > different from earlier. Keep the alignment same as earlier, it looks a
> > > little nicer.
> > >
> > > Regards,
> > > Mukesh
> > > > mtctr r0 /* put # words/line in ctr */
> > > > 3: addi r6,r6,8 /* copy a cache line */
> > > > --
> > > > 2.43.5
> > > >
^ permalink raw reply
* Re: [PATCH v16 18/18] arm64: vdso: Expose sigreturn address on vdso to the kernel
From: Thomas Weißschuh @ 2026-07-09 8:27 UTC (permalink / raw)
To: Jinjie Ruan
Cc: oleg, richard.henderson, mattst88, linmag7, linux,
catalin.marinas, will, kees, guoren, chenhuacai, kernel, geert,
tsbogend, James.Bottomley, deller, maddy, mpe, npiggin, chleroy,
pjw, palmer, aou, alex, hca, gor, agordeev, borntraeger, svens,
ysato, dalias, glaubitz, richard, anton.ivanov, johannes, luto,
tglx, mingo, bp, dave.hansen, hpa, chris, jcmvbkbc, peterz, wad,
thuth, mark.rutland, ada.coupriediaz, kevin.brodsky, linusw,
yeoreum.yun, song, james.morse, anshuman.khandual, broonie,
liqiang01, pengcan, ryan.roberts, yangtiezhu, sshegde, mchauras,
austin.kim, jchrist, arnd, sohil.mehta, andrew.cooper3, jgross,
kas, x86, linux-alpha, linux-kernel, linux-arm-kernel, linux-mm,
linux-csky, loongarch, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, linux-um
In-Reply-To: <d9c9686c-dfd8-4539-b301-8726bab7443b@huawei.com>
On Thu, Jul 09, 2026 at 04:15:15PM +0800, Jinjie Ruan wrote:
> On 7/9/2026 3:17 PM, Thomas Weißschuh wrote:
> > On Thu, Jul 09, 2026 at 02:37:05PM +0800, Jinjie Ruan wrote:
> >> On 6/30/2026 11:32 PM, Thomas Weißschuh wrote:
> >>> On Mon, Jun 29, 2026 at 09:06:16PM +0800, Jinjie Ruan wrote:
> > (..)
> >
> >>>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> >>>> index 592dd8668de4..5a0314a3c26e 100644
> >>>> --- a/arch/arm64/kernel/vdso.c
> >>>> +++ b/arch/arm64/kernel/vdso.c
> >>>> @@ -343,3 +343,19 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> >>>>
> >>>> return ret;
> >>>> }
> >>>> +
> >>>> +bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> >>>> +{
> >>>> + unsigned long sigtramp;
> >>>> +
> >>>> +#ifdef CONFIG_COMPAT
> >>>> + if (is_compat_task()) {
> >>>> + unsigned long sigpage = (unsigned long)current->mm->context.sigpage;
> >>>> +
> >>>> + return regs->pc >= sigpage && regs->pc < (sigpage + PAGE_SIZE);
> >>>> + }
> >>>> +#endif
> >>>> + sigtramp = (unsigned long)VDSO_SYMBOL(current->mm->context.vdso, sigtramp);
> >>>> +
> >>>> + return regs->pc == (sigtramp + 8);
> >>>
> >>> Instead of hardcoding 'sigtramp + 8' you could add a new label to the 'svc #0'
> >>> instruction and use that with VDSO_SYMBOL().
> >>
> >> It seems that the modification of __kernel_rt_sigreturn() is not recommended
> >
> > For the changes to the object code of the function this is obvious and
> > well explained in the comments.
> >
> > Such a label however would not change the object code of the function.
> > In fact it would not change any bit whatsoever in the final vDSO,
> > save for a new build ID.
>
> Yes, and using labels is easier to maintain than hardcoding offsets
> directly.
>
> Similar to the code below?
Exactly.
(...)
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index 592dd8668de4..609d7bcd8308 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -343,3 +343,19 @@ int arch_setup_additional_pages(struct linux_binprm
> *bprm, int uses_interp)
>
> return ret;
> }
> +
> +bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> +{
> + unsigned long sigtramp;
Could be named better now.
> +#ifdef CONFIG_COMPAT
> + if (is_compat_task()) {
> + unsigned long sigpage = (unsigned
> long)current->mm->context.sigpage;
> +
> + return regs->pc >= sigpage && regs->pc < (sigpage +
> PAGE_SIZE);
> + }
> +#endif
> + sigtramp = (unsigned long)VDSO_SYMBOL(current->mm->context.vdso,
> sigreturn_landing_pad);
> +
> + return regs->pc == sigtramp;
> +}
> diff --git a/arch/arm64/kernel/vdso/sigreturn.S
> b/arch/arm64/kernel/vdso/sigreturn.S
> index 0e18729abc3b..8d2d413ff45e 100644
> --- a/arch/arm64/kernel/vdso/sigreturn.S
> +++ b/arch/arm64/kernel/vdso/sigreturn.S
> @@ -73,6 +73,7 @@ SYM_CODE_START(__kernel_rt_sigreturn)
> mov x8, #__NR_rt_sigreturn
> // PLEASE DO NOT MODIFY
> svc #0
> + SYM_INNER_LABEL(__sigreturn_landing_pad, SYM_L_GLOBAL)
> // PLEASE DO NOT MODIFY
> // .cfi_endproc
> SYM_CODE_END(__kernel_rt_sigreturn)
> diff --git a/arch/arm64/kernel/vdso/vdso.lds.S
> b/arch/arm64/kernel/vdso/vdso.lds.S
> index 52314be29191..5fee2927e4c5 100644
> --- a/arch/arm64/kernel/vdso/vdso.lds.S
> +++ b/arch/arm64/kernel/vdso/vdso.lds.S
> @@ -104,6 +104,7 @@ VERSION
> __kernel_clock_gettime;
> __kernel_clock_getres;
> __kernel_getrandom;
> + __sigreturn_landing_pad;
This should not be done. The symbol is not intended to be used by userspace.
> local: *;
> };
> }
> @@ -112,3 +113,4 @@ VERSION
> * Make the sigreturn code visible to the kernel.
> */
> VDSO_sigtramp = __kernel_rt_sigreturn;
> +VDSO_sigreturn_landing_pad = __sigreturn_landing_pad;
^ permalink raw reply
* Re: [PATCH v16 18/18] arm64: vdso: Expose sigreturn address on vdso to the kernel
From: Jinjie Ruan @ 2026-07-09 8:15 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: oleg, richard.henderson, mattst88, linmag7, linux,
catalin.marinas, will, kees, guoren, chenhuacai, kernel, geert,
tsbogend, James.Bottomley, deller, maddy, mpe, npiggin, chleroy,
pjw, palmer, aou, alex, hca, gor, agordeev, borntraeger, svens,
ysato, dalias, glaubitz, richard, anton.ivanov, johannes, luto,
tglx, mingo, bp, dave.hansen, hpa, chris, jcmvbkbc, peterz, wad,
thuth, mark.rutland, ada.coupriediaz, kevin.brodsky, linusw,
yeoreum.yun, song, james.morse, anshuman.khandual, broonie,
liqiang01, pengcan, ryan.roberts, yangtiezhu, sshegde, mchauras,
austin.kim, jchrist, arnd, sohil.mehta, andrew.cooper3, jgross,
kas, x86, linux-alpha, linux-kernel, linux-arm-kernel, linux-mm,
linux-csky, loongarch, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, linux-um
In-Reply-To: <20260709090525-b1e5ae06-1fb4-454e-919c-6503dcf3d073@linutronix.de>
On 7/9/2026 3:17 PM, Thomas Weißschuh wrote:
> On Thu, Jul 09, 2026 at 02:37:05PM +0800, Jinjie Ruan wrote:
>> On 6/30/2026 11:32 PM, Thomas Weißschuh wrote:
>>> On Mon, Jun 29, 2026 at 09:06:16PM +0800, Jinjie Ruan wrote:
> (..)
>
>>>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
>>>> index 592dd8668de4..5a0314a3c26e 100644
>>>> --- a/arch/arm64/kernel/vdso.c
>>>> +++ b/arch/arm64/kernel/vdso.c
>>>> @@ -343,3 +343,19 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
>>>>
>>>> return ret;
>>>> }
>>>> +
>>>> +bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
>>>> +{
>>>> + unsigned long sigtramp;
>>>> +
>>>> +#ifdef CONFIG_COMPAT
>>>> + if (is_compat_task()) {
>>>> + unsigned long sigpage = (unsigned long)current->mm->context.sigpage;
>>>> +
>>>> + return regs->pc >= sigpage && regs->pc < (sigpage + PAGE_SIZE);
>>>> + }
>>>> +#endif
>>>> + sigtramp = (unsigned long)VDSO_SYMBOL(current->mm->context.vdso, sigtramp);
>>>> +
>>>> + return regs->pc == (sigtramp + 8);
>>>
>>> Instead of hardcoding 'sigtramp + 8' you could add a new label to the 'svc #0'
>>> instruction and use that with VDSO_SYMBOL().
>>
>> It seems that the modification of __kernel_rt_sigreturn() is not recommended
>
> For the changes to the object code of the function this is obvious and
> well explained in the comments.
>
> Such a label however would not change the object code of the function.
> In fact it would not change any bit whatsoever in the final vDSO,
> save for a new build ID.
Yes, and using labels is easier to maintain than hardcoding offsets
directly.
Similar to the code below?
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -86,6 +86,7 @@ config ARM64
select ARCH_SUPPORTS_SCHED_SMT
select ARCH_SUPPORTS_SCHED_CLUSTER
select ARCH_SUPPORTS_SCHED_MC
+ select ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT
select ARCH_WANT_DEFAULT_BPF_JIT
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index d2779d604c7b..a8b232c5c6d9 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -293,6 +293,7 @@ static inline int arch_check_elf(void *ehdr, bool
has_interp,
return 0;
}
+extern bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs);
#endif /* !__ASSEMBLER__ */
#endif
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 592dd8668de4..609d7bcd8308 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -343,3 +343,19 @@ int arch_setup_additional_pages(struct linux_binprm
*bprm, int uses_interp)
return ret;
}
+
+bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
+{
+ unsigned long sigtramp;
+
+#ifdef CONFIG_COMPAT
+ if (is_compat_task()) {
+ unsigned long sigpage = (unsigned
long)current->mm->context.sigpage;
+
+ return regs->pc >= sigpage && regs->pc < (sigpage +
PAGE_SIZE);
+ }
+#endif
+ sigtramp = (unsigned long)VDSO_SYMBOL(current->mm->context.vdso,
sigreturn_landing_pad);
+
+ return regs->pc == sigtramp;
+}
diff --git a/arch/arm64/kernel/vdso/sigreturn.S
b/arch/arm64/kernel/vdso/sigreturn.S
index 0e18729abc3b..8d2d413ff45e 100644
--- a/arch/arm64/kernel/vdso/sigreturn.S
+++ b/arch/arm64/kernel/vdso/sigreturn.S
@@ -73,6 +73,7 @@ SYM_CODE_START(__kernel_rt_sigreturn)
mov x8, #__NR_rt_sigreturn
// PLEASE DO NOT MODIFY
svc #0
+ SYM_INNER_LABEL(__sigreturn_landing_pad, SYM_L_GLOBAL)
// PLEASE DO NOT MODIFY
// .cfi_endproc
SYM_CODE_END(__kernel_rt_sigreturn)
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S
b/arch/arm64/kernel/vdso/vdso.lds.S
index 52314be29191..5fee2927e4c5 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -104,6 +104,7 @@ VERSION
__kernel_clock_gettime;
__kernel_clock_getres;
__kernel_getrandom;
+ __sigreturn_landing_pad;
local: *;
};
}
@@ -112,3 +113,4 @@ VERSION
* Make the sigreturn code visible to the kernel.
*/
VDSO_sigtramp = __kernel_rt_sigreturn;
+VDSO_sigreturn_landing_pad = __sigreturn_landing_pad;
>
>
> Thomas
>
^ permalink raw reply related
* Re: [PATCH] syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
From: Jinjie Ruan @ 2026-07-09 7:59 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: chenhuacai, kernel, maddy, mpe, npiggin, chleroy, pjw, palmer,
aou, alex, hca, gor, agordeev, borntraeger, svens, tglx, mingo,
bp, dave.hansen, hpa, nathan, kees, xur, peterz, gourry,
lukas.bulwahn, ryan.roberts, yangtiezhu, sshegde, mchauras,
austin.kim, arnd, jchrist, x86, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20260709093404-0b19988f-8d19-4fae-86d8-396aa747307d@linutronix.de>
On 7/9/2026 3:36 PM, Thomas Weißschuh wrote:
> On Thu, Jul 09, 2026 at 03:28:03PM +0800, Jinjie Ruan wrote:
>> Currently, only x86 genuinely implements and supports Syscall User
>> Dispatch (SUD). Multiple architectures provide a stub
>> arch_syscall_is_vdso_sigreturn() returning 'false' simply to satisfy
>> GENERIC_ENTRY compilation, which creates a false impression of feature
>> support.
>>
>> Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH to decouple this mechanism
>> from GENERIC_ENTRY. Select it exclusively on x86 and remove the redundant
>> stub functions from other architectures.
>
> Nice, this confused me before.
>
>> Link: https://lore.kernel.org/linux-arm-kernel/akZgV0Y4YAmB43_g@J2N7QTR9R3.cambridge.arm.com/
>> Cc: Thomas Gleixner <tglx@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
>> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>> Suggested-by: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/Kconfig | 1 +
>> arch/loongarch/include/asm/syscall.h | 6 ------
>> arch/powerpc/include/asm/syscall.h | 5 -----
>> arch/riscv/include/asm/syscall.h | 5 -----
>> arch/s390/include/asm/syscall.h | 5 -----
>> arch/x86/Kconfig | 1 +
>> 6 files changed, 2 insertions(+), 21 deletions(-)
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 0c01521c2f3f..393d0fb75eac 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -116,6 +116,7 @@ config GENERIC_ENTRY
>>
>> config SYSCALL_USER_DISPATCH
>> bool "Syscall User Dispatch"
>> + depends on ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
>
> ARCH_SUPPORTS_SYSCALL_USER_DISPATCH is not declared as a config option,
> so the 'select' will not do anything. Needs this:
>
> config ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
> bool
Yes, this is missing here.
>
>> depends on GENERIC_ENTRY
>> default y
>> help
>
> (...)
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix comment typos
From: Salman Farooq @ 2026-07-09 7:43 UTC (permalink / raw)
To: amachhiw
Cc: chleroy, kvm, linux-kernel, linuxppc-dev, maddy, mpe, npiggin,
salman.farooq3310
In-Reply-To: <20260709125357.49cafeb6-1b-amachhiw@linux.ibm.com>
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> Regardless, since this patch has no functional or code change, you may
> want to add a 'trivial' suffix to the patch title, e.g.:
>
> KVM: PPC: Book3S HV: trivial: Fix comment typos
Thanks for pointing that out, and for the very useful references.
I wasn't aware of this convention. I will follow it and read up on
other conventions for future patches.
Salman
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Set irqfd->producer only on success
From: Vaibhav Jain @ 2026-07-09 7:39 UTC (permalink / raw)
To: leixiang
Cc: seanjc, pbonzini, stable, leixiang, Madhavan Srinivasan,
Nicholas Piggin, Michael Ellerman, Christophe Leroy (CS GROUP),
Suresh Warrier, Paul Mackerras, linuxppc-dev, kvm, linux-kernel
In-Reply-To: <20260709055755.31297-1-leixiang@kylinos.cn>
Hi leixiang,
Thanks for catching and fixing this for kvm-hv:
leixiang <leixiang@kylinos.cn> writes:
> Set irqfd->producer only after kvmppc_set_passthru_irq() succeeds to
> avoid leaving a dangling pointer on failure. The bypass manager does
> not register a failed producer, so the pointer is never cleared.
>
> Fixes: c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass")
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: leixiang <leixiang@kylinos.cn>
> ---
> arch/powerpc/kvm/book3s_hv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 61dbeea317f3..ff7b25629125 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6111,12 +6111,12 @@ static int kvmppc_irq_bypass_add_producer_hv(struct irq_bypass_consumer *cons,
> struct kvm_kernel_irqfd *irqfd =
> container_of(cons, struct kvm_kernel_irqfd, consumer);
>
> - irqfd->producer = prod;
> -
> ret = kvmppc_set_passthru_irq(irqfd->kvm, prod->irq, irqfd->gsi);
> if (ret)
> pr_info("kvmppc_set_passthru_irq (irq %d, gsi %d) fails: %d\n",
> prod->irq, irqfd->gsi, ret);
> + else
> + irqfd->producer = prod;
>
> return ret;
> }
> --
> 2.45.0
>
Proposed new error handling path looks better compared to v1 of the
patch. Also agree to the changes made.
Hence,
Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com>
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH] syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
From: Thomas Weißschuh @ 2026-07-09 7:36 UTC (permalink / raw)
To: Jinjie Ruan
Cc: chenhuacai, kernel, maddy, mpe, npiggin, chleroy, pjw, palmer,
aou, alex, hca, gor, agordeev, borntraeger, svens, tglx, mingo,
bp, dave.hansen, hpa, nathan, kees, xur, peterz, gourry,
lukas.bulwahn, ryan.roberts, yangtiezhu, sshegde, mchauras,
austin.kim, arnd, jchrist, x86, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20260709072803.3843948-1-ruanjinjie@huawei.com>
On Thu, Jul 09, 2026 at 03:28:03PM +0800, Jinjie Ruan wrote:
> Currently, only x86 genuinely implements and supports Syscall User
> Dispatch (SUD). Multiple architectures provide a stub
> arch_syscall_is_vdso_sigreturn() returning 'false' simply to satisfy
> GENERIC_ENTRY compilation, which creates a false impression of feature
> support.
>
> Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH to decouple this mechanism
> from GENERIC_ENTRY. Select it exclusively on x86 and remove the redundant
> stub functions from other architectures.
Nice, this confused me before.
> Link: https://lore.kernel.org/linux-arm-kernel/akZgV0Y4YAmB43_g@J2N7QTR9R3.cambridge.arm.com/
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/Kconfig | 1 +
> arch/loongarch/include/asm/syscall.h | 6 ------
> arch/powerpc/include/asm/syscall.h | 5 -----
> arch/riscv/include/asm/syscall.h | 5 -----
> arch/s390/include/asm/syscall.h | 5 -----
> arch/x86/Kconfig | 1 +
> 6 files changed, 2 insertions(+), 21 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 0c01521c2f3f..393d0fb75eac 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -116,6 +116,7 @@ config GENERIC_ENTRY
>
> config SYSCALL_USER_DISPATCH
> bool "Syscall User Dispatch"
> + depends on ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
ARCH_SUPPORTS_SYSCALL_USER_DISPATCH is not declared as a config option,
so the 'select' will not do anything. Needs this:
config ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
bool
> depends on GENERIC_ENTRY
> default y
> help
(...)
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix comment typos
From: Amit Machhiwal @ 2026-07-09 7:29 UTC (permalink / raw)
To: Salman Farooq
Cc: maddy, npiggin, mpe, chleroy, linuxppc-dev, kvm, linux-kernel
In-Reply-To: <20260702030344.2211462-1-salman.farooq3310@gmail.com>
On 2026/07/02 08:03 AM, Salman Farooq wrote:
> Fix two instances of a misspelled word in comments.
>
> Signed-off-by: Salman Farooq <salman.farooq3310@gmail.com>
> ---
> arch/powerpc/kvm/book3s_hv_uvmem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I agree with Ritesh on the amount of churn such misspell fixes may
cause.
Regardless, since this patch has no functional or code change, you may
want to add a 'trivial' suffix to the patch title, e.g.:
KVM: PPC: Book3S HV: trivial: Fix comment typos
This convention is used to indicate non-functional changes, making it
easier for maintainers to apply without worrying about regressions. See
[1] and [2] for precedent.
[1] https://git.kernel.org/powerpc/c/d2827e5e2e0f0941a651f4b1ca5e9b778c4b5293
[2] https://lore.kernel.org/all/87fr3vvfvq.fsf@vajain21.in.ibm.com/
~Amit
>
> diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
> index 5fbb95d90e99..6ac8364a7639 100644
> --- a/arch/powerpc/kvm/book3s_hv_uvmem.c
> +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
> @@ -163,7 +163,7 @@ static DEFINE_SPINLOCK(kvmppc_uvmem_bitmap_lock);
> * All its GFNs are moved to Normal-GFNs.
> *
> * UV_TERMINATE transitions the secure-VM back to normal-VM. All
> - * the secure-GFN and shared-GFNs are tranistioned to normal-GFN
> + * the secure-GFN and shared-GFNs are transitioned to normal-GFN
> * Note: The contents of the normal-GFN is undefined at this point.
> *
> * GFN state implementation:
> @@ -1010,7 +1010,7 @@ static vm_fault_t kvmppc_uvmem_migrate_to_ram(struct vm_fault *vmf)
> /*
> * Release the device PFN back to the pool
> *
> - * Gets called when secure GFN tranistions from a secure-PFN
> + * Gets called when secure GFN transitions from a secure-PFN
> * to a normal PFN during H_SVM_PAGE_OUT.
> * Gets called with kvm->arch.uvmem_lock held.
> */
> --
> 2.55.0
>
^ permalink raw reply
* [PATCH] syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
From: Jinjie Ruan @ 2026-07-09 7:28 UTC (permalink / raw)
To: chenhuacai, kernel, maddy, mpe, npiggin, chleroy, pjw, palmer,
aou, alex, hca, gor, agordeev, borntraeger, svens, tglx, mingo,
bp, dave.hansen, hpa, nathan, kees, xur, peterz, gourry,
lukas.bulwahn, ryan.roberts, ruanjinjie, yangtiezhu, sshegde,
mchauras, austin.kim, arnd, jchrist, x86, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390
Currently, only x86 genuinely implements and supports Syscall User
Dispatch (SUD). Multiple architectures provide a stub
arch_syscall_is_vdso_sigreturn() returning 'false' simply to satisfy
GENERIC_ENTRY compilation, which creates a false impression of feature
support.
Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH to decouple this mechanism
from GENERIC_ENTRY. Select it exclusively on x86 and remove the redundant
stub functions from other architectures.
Link: https://lore.kernel.org/linux-arm-kernel/akZgV0Y4YAmB43_g@J2N7QTR9R3.cambridge.arm.com/
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/Kconfig | 1 +
arch/loongarch/include/asm/syscall.h | 6 ------
arch/powerpc/include/asm/syscall.h | 5 -----
arch/riscv/include/asm/syscall.h | 5 -----
arch/s390/include/asm/syscall.h | 5 -----
arch/x86/Kconfig | 1 +
6 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 0c01521c2f3f..393d0fb75eac 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -116,6 +116,7 @@ config GENERIC_ENTRY
config SYSCALL_USER_DISPATCH
bool "Syscall User Dispatch"
+ depends on ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
depends on GENERIC_ENTRY
default y
help
diff --git a/arch/loongarch/include/asm/syscall.h b/arch/loongarch/include/asm/syscall.h
index df8ea223c77b..d9275010f548 100644
--- a/arch/loongarch/include/asm/syscall.h
+++ b/arch/loongarch/include/asm/syscall.h
@@ -84,10 +84,4 @@ static inline int syscall_get_arch(struct task_struct *task)
return AUDIT_ARCH_LOONGARCH64;
#endif
}
-
-static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
-{
- return false;
-}
-
#endif /* __ASM_LOONGARCH_SYSCALL_H */
diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index 834fcc4f7b54..4b3c52ed6e9d 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -139,9 +139,4 @@ static inline int syscall_get_arch(struct task_struct *task)
else
return AUDIT_ARCH_PPC64;
}
-
-static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
-{
- return false;
-}
#endif /* _ASM_SYSCALL_H */
diff --git a/arch/riscv/include/asm/syscall.h b/arch/riscv/include/asm/syscall.h
index 8067e666a4ca..987c9a78806f 100644
--- a/arch/riscv/include/asm/syscall.h
+++ b/arch/riscv/include/asm/syscall.h
@@ -112,11 +112,6 @@ static inline void syscall_handler(struct pt_regs *regs, ulong syscall)
regs->a0 = fn(regs);
}
-static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
-{
- return false;
-}
-
asmlinkage long sys_riscv_flush_icache(uintptr_t, uintptr_t, uintptr_t);
asmlinkage long sys_riscv_hwprobe(struct riscv_hwprobe *, size_t, size_t,
diff --git a/arch/s390/include/asm/syscall.h b/arch/s390/include/asm/syscall.h
index 4271e4169f45..5f310caad1fc 100644
--- a/arch/s390/include/asm/syscall.h
+++ b/arch/s390/include/asm/syscall.h
@@ -89,11 +89,6 @@ static inline int syscall_get_arch(struct task_struct *task)
return AUDIT_ARCH_S390X;
}
-static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
-{
- return false;
-}
-
#define SYSCALL_FMT_0
#define SYSCALL_FMT_1 , "0" (r2)
#define SYSCALL_FMT_2 , "d" (r3) SYSCALL_FMT_1
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bdad90f210e4..f3f8ad107eeb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -335,6 +335,7 @@ config X86
select SCHED_SMT if SMP
select ARCH_SUPPORTS_SCHED_CLUSTER if SMP
select ARCH_SUPPORTS_SCHED_MC if SMP
+ select ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
select HAVE_SINGLE_FTRACE_DIRECT_OPS if X86_64 && DYNAMIC_FTRACE_WITH_DIRECT_CALLS
config INSTRUCTION_DECODER
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: Book3S HV: Fix comment typos
From: Salman Farooq @ 2026-07-09 7:23 UTC (permalink / raw)
To: ritesh.list
Cc: chleroy, kvm, linux-kernel, linuxppc-dev, maddy, mpe, npiggin,
salman.farooq3310
In-Reply-To: <8q7kwssv.ritesh.list@gmail.com>
Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:
> Not sure what this will really get us and what is our maintainer take on
> such spelling mistake fixes. I definitely hope we won't churn out a lot
> of patches just to fix simple spell mistakes.
> But FWIW, the change looks good to me, so:
>
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Thank you for the review and for taking the time to look at it despite
the reservations, I really appreciate it as a first-time kernel contributor.
Salman
^ permalink raw reply
* Re: [PATCH v16 18/18] arm64: vdso: Expose sigreturn address on vdso to the kernel
From: Thomas Weißschuh @ 2026-07-09 7:17 UTC (permalink / raw)
To: Jinjie Ruan
Cc: oleg, richard.henderson, mattst88, linmag7, linux,
catalin.marinas, will, kees, guoren, chenhuacai, kernel, geert,
tsbogend, James.Bottomley, deller, maddy, mpe, npiggin, chleroy,
pjw, palmer, aou, alex, hca, gor, agordeev, borntraeger, svens,
ysato, dalias, glaubitz, richard, anton.ivanov, johannes, luto,
tglx, mingo, bp, dave.hansen, hpa, chris, jcmvbkbc, peterz, wad,
thuth, mark.rutland, ada.coupriediaz, kevin.brodsky, linusw,
yeoreum.yun, song, james.morse, anshuman.khandual, broonie,
liqiang01, pengcan, ryan.roberts, yangtiezhu, sshegde, mchauras,
austin.kim, jchrist, arnd, sohil.mehta, andrew.cooper3, jgross,
kas, x86, linux-alpha, linux-kernel, linux-arm-kernel, linux-mm,
linux-csky, loongarch, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, linux-um
In-Reply-To: <21875fb4-434b-480d-b68b-e2ffd5fff5ae@huawei.com>
On Thu, Jul 09, 2026 at 02:37:05PM +0800, Jinjie Ruan wrote:
> On 6/30/2026 11:32 PM, Thomas Weißschuh wrote:
> > On Mon, Jun 29, 2026 at 09:06:16PM +0800, Jinjie Ruan wrote:
(..)
> >> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> >> index 592dd8668de4..5a0314a3c26e 100644
> >> --- a/arch/arm64/kernel/vdso.c
> >> +++ b/arch/arm64/kernel/vdso.c
> >> @@ -343,3 +343,19 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> >>
> >> return ret;
> >> }
> >> +
> >> +bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> >> +{
> >> + unsigned long sigtramp;
> >> +
> >> +#ifdef CONFIG_COMPAT
> >> + if (is_compat_task()) {
> >> + unsigned long sigpage = (unsigned long)current->mm->context.sigpage;
> >> +
> >> + return regs->pc >= sigpage && regs->pc < (sigpage + PAGE_SIZE);
> >> + }
> >> +#endif
> >> + sigtramp = (unsigned long)VDSO_SYMBOL(current->mm->context.vdso, sigtramp);
> >> +
> >> + return regs->pc == (sigtramp + 8);
> >
> > Instead of hardcoding 'sigtramp + 8' you could add a new label to the 'svc #0'
> > instruction and use that with VDSO_SYMBOL().
>
> It seems that the modification of __kernel_rt_sigreturn() is not recommended
For the changes to the object code of the function this is obvious and
well explained in the comments.
Such a label however would not change the object code of the function.
In fact it would not change any bit whatsoever in the final vDSO,
save for a new build ID.
Thomas
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix comment typos
From: Ritesh Harjani @ 2026-07-09 7:01 UTC (permalink / raw)
To: Salman Farooq, maddy
Cc: npiggin, mpe, chleroy, linuxppc-dev, kvm, linux-kernel,
Salman Farooq
In-Reply-To: <20260702030344.2211462-1-salman.farooq3310@gmail.com>
Salman Farooq <salman.farooq3310@gmail.com> writes:
> Fix two instances of a misspelled word in comments.
>
Not sure what this will really get us and what is our maintainer take on
such spelling mistake fixes. I definitely hope we won't churn out a lot
of patches just to fix simple spell mistakes.
But FWIW, the change looks good to me, so:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Signed-off-by: Salman Farooq <salman.farooq3310@gmail.com>
> ---
> arch/powerpc/kvm/book3s_hv_uvmem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
> index 5fbb95d90e99..6ac8364a7639 100644
> --- a/arch/powerpc/kvm/book3s_hv_uvmem.c
> +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
> @@ -163,7 +163,7 @@ static DEFINE_SPINLOCK(kvmppc_uvmem_bitmap_lock);
> * All its GFNs are moved to Normal-GFNs.
> *
> * UV_TERMINATE transitions the secure-VM back to normal-VM. All
> - * the secure-GFN and shared-GFNs are tranistioned to normal-GFN
> + * the secure-GFN and shared-GFNs are transitioned to normal-GFN
> * Note: The contents of the normal-GFN is undefined at this point.
> *
> * GFN state implementation:
> @@ -1010,7 +1010,7 @@ static vm_fault_t kvmppc_uvmem_migrate_to_ram(struct vm_fault *vmf)
> /*
> * Release the device PFN back to the pool
> *
> - * Gets called when secure GFN tranistions from a secure-PFN
> + * Gets called when secure GFN transitions from a secure-PFN
> * to a normal PFN during H_SVM_PAGE_OUT.
> * Gets called with kvm->arch.uvmem_lock held.
> */
> --
> 2.55.0
^ 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