On 09.02.2026 13:35, Oleksii Kurochko wrote: > On 2/9/26 10:51 AM, Jan Beulich wrote: >> On 09.02.2026 10:40, Oleksii Kurochko wrote: >>> On 2/9/26 10:07 AM, Jan Beulich wrote: >>>> On 06.02.2026 17:36, Oleksii Kurochko wrote: >>>>> On 1/22/26 5:47 PM, Oleksii Kurochko wrote: >>>>>> Add a RISC-V implementation of vcpu_kick(), which unblocks the target >>>>>> vCPU and sends an event check IPI if the vCPU was running on another >>>>>> processor. This mirrors the behavior of Arm and enables proper vCPU >>>>>> wakeup handling on RISC-V. >>>>>> >>>>>> Remove the stub implementation from stubs.c, as it is now provided by >>>>>> arch/riscv/domain.c. >>>>>> >>>>>> Signed-off-by: Oleksii Kurochko <[email protected]> >>>>>> Acked-by: Jan Beulich <[email protected]> >>>>>> --- >>>>>> Changes in v2: >>>>>> - Add Acked-by: Jan Beulich <[email protected]>. >>>>>> --- >>>>>> xen/arch/riscv/domain.c | 14 ++++++++++++++ >>>>>> xen/arch/riscv/stubs.c | 5 ----- >>>>>> 2 files changed, 14 insertions(+), 5 deletions(-) >>>>>> >>>>>> diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c >>>>>> index e38c0db62cac..13ac384c4b76 100644 >>>>>> --- a/xen/arch/riscv/domain.c >>>>>> +++ b/xen/arch/riscv/domain.c >>>>>> @@ -1,8 +1,10 @@ >>>>>> /* SPDX-License-Identifier: GPL-2.0-only */ >>>>>> >>>>>> +#include <xen/cpumask.h> >>>>>> #include <xen/init.h> >>>>>> #include <xen/mm.h> >>>>>> #include <xen/sched.h> >>>>>> +#include <xen/smp.h> >>>>>> #include <xen/vmap.h> >>>>>> >>>>>> #include <asm/bitops.h> >>>>>> @@ -240,3 +242,15 @@ void vcpu_sync_interrupts(struct vcpu *v) >>>>>> # error "Update vsieh" >>>>>> #endif >>>>>> } >>>>>> + >>>>>> +void vcpu_kick(struct vcpu *v) >>>>>> +{ >>>>>> + bool running = v->is_running; >>>>>> + >>>>>> + vcpu_unblock(v); >>>>>> + if ( running && v != current ) >>>>>> + { >>>>>> + perfc_incr(vcpu_kick); >>>>> Because of this it is needed to introduce: >>>>> PERFCOUNTER(vcpu_kick, "vcpu: notify other vcpu") >>>>> Otherwise randconfig build will fail when CONFIG_PERF_COUNTERS=y. >>>>> >>>>> I would like to ask if it would be okay to add it >>>>> xen/include/xen/perfc_defn.h >>>>> just after PERFCOUNTER(need_flush_tlb_flush,...) or would it be better to >>>>> have >>>>> it in arch specific perfc_defn.h? >>>> Arch-specific please - it's not used by x86 nor ppc. >>> Then I will do the following changes: >>> >>> diff --git a/xen/arch/riscv/include/asm/Makefile >>> b/xen/arch/riscv/include/asm/Makefile >>> index 3824f31c395c..86c56251d5d7 100644 >>> --- a/xen/arch/riscv/include/asm/Makefile >>> +++ b/xen/arch/riscv/include/asm/Makefile >>> @@ -7,7 +7,6 @@ generic-y += hypercall.h >>> generic-y += iocap.h >>> generic-y += irq-dt.h >>> generic-y += percpu.h >>> -generic-y += perfc_defn.h >>> generic-y += random.h >>> generic-y += softirq.h >>> generic-y += vm_event.h >>> diff --git a/xen/arch/riscv/include/asm/perfc_defn.h >>> b/xen/arch/riscv/include/asm/perfc_defn.h >>> new file mode 100644 >>> index 000000000000..4fc161f1abad >>> --- /dev/null >>> +++ b/xen/arch/riscv/include/asm/perfc_defn.h >>> @@ -0,0 +1,7 @@ >>> +/* This file is intended to be included multiple times. */ >>> +/*#ifndef __XEN_PERFC_DEFN_H__*/ >>> +/*#define __XEN_PERFC_DEFN_H__*/ >>> + >>> +PERFCOUNTER(vcpu_kick, "vcpu: notify other vcpu") >>> + >>> +/*#endif*/ /* __XEN_PERFC_DEFN_H__ */ >>> >>> and add the following to commit message: >>> Since vcpu_kick() calls perfc_incr(vcpu_kick), add perfcounter for >>> vcpu_kick to handle the case when CONFIG_PERF_COUNTERS=y. Although >>> CONFIG_PERF_COUNTERS is not enabled by default, it can be enabled, >>> for example, by randconfig what will lead to CI build issues. >>> >>> Note that I keep __XEN_PERFC_DEFN_H__ as other archictectures use the same, >>> not something like ASM__<arch>__PERFC_DEFN_H. >> Please don't copy this mistake. I actually question the commented-out pre- >> processor directives altogether: Misra also has a rule against commented- >> out code (directive 4.4, which we didn't accept [yet], but which exists >> nevertheless). Yet at the very least what's commented out should not be >> obviously wrong. > > Do I understand correctly that it would be acceptable to simply drop the > commented-out preprocessor directives and keep only /* This file is intended > to be included multiple times. */ ?
I think so, yes. You could simply check how the same situation is covered for elsewhere. Jan
