Re: [PATCH v3 13/23] xen/riscv: introduce per-vCPU IMSIC state

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 6/22/26 4:46 PM, Jan Beulich wrote:
> On 17.06.2026 13:17, Oleksii Kurochko wrote:
> > @@ -61,7 +62,24 @@ struct imsic_config {
> >       spinlock_t lock;
> >   };
> >   
> > +struct vimsic_state {
> > +    /* IMSIC VS-file */
> > +    rwlock_t vsfile_lock;
> > +    /*
> > +     * (guest_file_id == 0) -> s/w IMSIC VS-file
> > +     * (guest_file_id > 0) -> h/w IMSIC VS-file
> > +     */
> > +    unsigned int guest_file_id;
> > +    /*
> > +     * (vsfile_pcpu >= 0) => h/w IMSIC VS-file
> DYM "< NR_CPUS"? Else the above conflicts with ...
Agree, it should be '< NR_CPUS'.

> > +     * (vsfile_pcpu == NR_CPUS) => s/w IMSIC VS-file
> ... this.
>
> As to the h/w vs s/w options: I take it that e.g. guest_file_id > 0 and
> vsfile_pcpu == NR_CPUS is an impossible combination?
Yes, if we have assigned h/w guest interrupt file it should be connected 
to pCPU.
 In which case
> re-arranging commentary may want considering:
>
>      /*
>       * s/w IMSIC VS-file -> guest_file_id == 0
>       * h/w IMSIC VS-file -> guest_file_id > 0
>       */
>      unsigned int guest_file_id;
>      /*
>       * s/w IMSIC VS-file -> vsfile_pcpu == NR_CPUS
>       * h/w IMSIC VS-file -> vsfile_pcpu < NR_CPUS
>       */
>      unsigned int vsfile_pcpu;
Good point. I will apply this.

> As to guest_file_id: In vcpu_imsic_init() you store IMPOSSIBLE_GUEST_FILE_ID,
> yet that value isn't mentioned here at all.
Good point too. Actually I think that this definition isn't really 
needed as software IMSIC interrupt file could be counted as always 
available and so IMPOSSIBLE_GUEST_FILE_ID could be just dropped.
Thanks.

~ Oleksii