Re: [PATCH v2 09/16] xen/riscv: introduce vcpu_kick() implementation

[Jan Beulich <jbeulich@xxxxxxxx>]

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 <oleksii.kurochko@xxxxxxxxx>
>>>>>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>> ---
>>>>>> Changes in v2:
>>>>>>     - Add Acked-by: Jan Beulich <jbeulich@xxxxxxxx>.
>>>>>> ---
>>>>>>     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