Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore

On 13.08.2026 11:34, Oleksii Kurochko wrote:
> On 8/13/26 11:30 AM, Baptiste Le Duc wrote:
>>> --- a/xen/arch/riscv/imsic.c
>>> +++ b/xen/arch/riscv/imsic.c
>>> @@ -20,6 +20,7 @@
>>>   #include <xen/init.h>
>>>   #include <xen/libfdt/libfdt.h>
>>>   #include <xen/macros.h>
>>> +#include <xen/rwlock.h>
>>>   #include <xen/sched.h>
>>>   #include <xen/smp.h>
>>>   #include <xen/spinlock.h>
>>> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>>>       return res;
>>>   }
>>>   
>>> +void imsic_state_save(struct vcpu *v)
>>> +{
>>> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
>>> +    unsigned long flags;
>>> +
>>> +    /*
>>> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
>>> +     * should be done in this case.
>>> +     */
>>> +    if ( !vcpu_guest_file_id(v) )
>>> +        return;
>>
>>
>>> +
>>> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
>>> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);
>>
>> How will you detect a migration is needed? Don't you need to first know
>> if ->vsfile_pcpu is different to cpuid_to_hartid(v->processor)? (I
>> didn't take a look to other patchs for the moment, so the
>> explanations might be later.)
> 
> Migration (if you are speaking about migration of vCPU from one pCPU to 
> another) is completely different path. Look at sched_move_irqs().

See how terminology is important. As said elsewhere, "save state" and
"restore state" don't make clear at all in which situation they're to be
used.

Also, can both of you please adjust Roger's email address when replying?

Jan