Re: [PATCH v3 30/39] xen/riscv: implement APLIC-IMSIC-hart sync barrier for vCPU migration

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 11/5/26 4:59 PM, Baptiste Le Duc wrote:
> On 11/5/26 4:51 PM, Oleksii Kurochko wrote:
> > On 11/5/26 4:32 PM, Baptiste Le Duc wrote:
> > > On 2026-11-05 15:21 +0100, Oleksii Kurochko wrote:
> > > > [ ... 348 lines skipped ... ]
> > > > > LGTM, but I wonder why, as I said in the original patch, sync_id is
> > > > > really needed.
> > > > I think that I am not understand your response. Could you please
> > > > re-phrase it?
> > > I'm questionning the need of the sync_id field as it will always be
> > > equal to imsic_cfg.nr_ids, couldn't we drop it?
> > It's equal to nr_ids by choice rather than by necessity: which identity
> > gets reserved is decided in a single place, imsic_parse_node(), and all
> > the users (the genmsi write, the pending bit the barrier spins on, the
> > limit on the APLIC sources and the ASSERT() in imsic_irq_enable()) refer
> > to it by its role rather than as "the last identity".
> >
> > Basically if one day someone will decide to come up with EIID 
> > allocator instead of using static allocation then it will be harder to 
> > find a places where to change.
> > So yes, it could be drooped but at the moment I think it is useful to 
> > have separate field or ,at least, as an option in asm/imsic.h:
> > static inline unsigned int imsic_sync_id(const struct imsic_config *cfg)
> > {
> >      return cfg->nr_ids;
> > }
> I prefer this as it would save space in imsic_config struct.
Thanks for the clarification. I'll go with that approach, then.

~ Oleksii