Re: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

On 9/24/26 4:25 PM, Baptiste Le Duc wrote:
>> While a vCPU is running, MSIs written to its h/w IMSIC guest interrupt
>> file are delivered straight to VS-mode. Once the vCPU is descheduled
>> nobody observes that file anymore, so a guest blocked on such an
>> interrupt would stay blocked until some unrelated event happens to
>> schedule it again.
>>
>> Let Xen observe the file in that window: on deschedule set the vCPU's
>> bit in HGEIE, which turns an interrupt pending in its VS-file into an
>> HS-level SGEI, and clear the bit again on schedule-in. HGEIP only
>> reports a file number, so to get from it back to a vCPU keep an
>> owners[] map per pCPU, filled by vgein_{assign,release} alongside the
>> VGEIN bitmap, and kick the vCPU it points at.
> Nit: I would reword the last sentence to make it more clear:
> 
>      HGEIP only reports an interrupt file number, so to find the vCPU to
>      kick, keep a per-pCPU owners[] array indexed by file number and
>      updated in vgein_assign()/vgein_release() together with the VGEIN
>      bitmap.
> 

LGTM: I will apply your suggestion.

>>   
>> +/*
>> + * Start to observe the interrupt file from HS-mode, the same way
>> + * imsic_ctxt_switch_from() does it for a vCPU which is switched out.
>> + *
>> + * The counterpart, clearing the bit of the interrupt file which is left
>> + * behind, is done by imsic_vsfile_local_read_clear(), which already runs on
>> + * the pCPU owning that file.
>> + */
>> +static void cf_check imsic_local_hgeie_set(void *data)
>> +{
>> +    const struct imsic_vsfile_data *idata = data;
>> +
>> +    csr_set(CSR_HGEIE, BIT(idata->hgei, UL));
>> +}
>> +
> Sorry I'm a bit lost here, are you doing that for vCPUs migration?
> Because in your commit message you only mentioned scheduled-out case
> which needs to have Xen observing the descheduled vCPU to re-scheduled
> it, but no other case that would need to have interrupt file observed is
> explained
> 

Yes, this is for migration. A vCPU can be migrated while it isn't
running: e.g. a blocked vCPU whose affinity is changed (it is moved by
sched_unit_migrate_finish() and stays blocked on the new pCPU), or the
vCPUs of a domain moved to another cpupool.

Before the migration, imsic_ctxt_switch_from() armed the HGEIE bit of
the vCPU's interrupt file on the old pCPU. That file is released as part
of the migration (and imsic_vsfile_local_read_clear() clears its HGEIE
bit), so afterwards nothing observes the vCPU's interrupts anymore: the
vCPU isn't switched in on the new pCPU, so imsic_ctxt_switch_from() 
never arms HGEIE for the new file. A blocked vCPU waiting for an MSI 
could then stay blocked until some unrelated event wakes it up, possibly 
never.

Hence imsic_local_hgeie_set() arms HGEIE for the new interrupt file on
the new pCPU. As HGEIP reflects the current state of the file, this also
covers an interrupt which was already pending in the old file and got
carried over: it raises an SGEI as soon as the bit is set.

For a vCPU which is about to run, this isn't needed, as 
imsic_ctxt_switch_to() clears the bit anyway.

I'll describe this case in the commit message:
```
The same applies to a vCPU which is migrated to another pCPU while it
isn't running. Its old interrupt file is released during the migration,
and the vCPU isn't switched in on the new pCPU until something wakes it
up, so nothing would observe the new interrupt file. Hence arm HGEIE for
the new interrupt file on the new pCPU in imsic_migrate_vcpu(), and
clear the bit of the old one in imsic_vsfile_local_read_clear(), which
already runs on the pCPU owning it.
```

Thanks!

~ Oleksii