Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 9/10/26 1:14 PM, Jan Beulich wrote:
> On 10.09.2026 12:37, Oleksii Kurochko wrote:
> > On 9/9/26 4:26 PM, Jan Beulich wrote:
> > > On 27.08.2026 17:20, Oleksii Kurochko wrote:
> > > > +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu,
> > > > +                              uint32_t base_val)
> > > > +{
> > > > +    unsigned int guest_id = vcpu_guest_file_id(target_vcpu);
> > > > +    unsigned long hart_field = aplic_hart_field(target_vcpu->processor);
> > > What guarantees target_vcpu's ->processor field to be meaningful at this
> > > point?
> > Good question. Considering the places where it is called, I would expect
> > target_vcpu->processor to have something meaningful, since it is called
> > from a place that can only be reached when the guest is running.
> >
> > Even without that, I don't think there is a big issue here, as
> > ->processor is initialized to 0 at allocation time. This means that the
> > target register will be configured in such a way that CPU 0 will handle
> > such IRQs.
> I may not have been explicit enough then: Whether the guest (as a whole)
> is running is of no interest. If the specific vCPU is running, all is fine.
> If the specific vCPU is in the process of being moved to a different CPU,
> and if you read ->processor just before the new value is put there, is
> all going to be fine as well? I doubt that.
You're right, and it's worse than a stale CPU number: v->processor is 
updated by the scheduler (sched_unit_migrate_finish()) before 
sched_move_irqs() -> imsic_migrate_vcpu() moves the interrupt file, so a 
concurrent vAPLIC TARGET write can combine the new CPU with the old 
guest file index (an MSI into someone else's file, which 
aplic_reconfigure_target(), which is introduced later in this patch 
series, won't catch), or compute a correct old target but write it after 
aplic_reconfigure_target() (the function which is called during 
migration to re-target irqs to new pCPU) has already scanned.
In v3 I'll (a) stop using ->processor and take the (guest_file_id, 
vsfile_cpu) pair, which imsic_update_state() updates atomically under 
vsfile_lock, and (b) do the snapshot plus the h/w TARGET write under 
aplic.lock, which aplic_reconfigure_target() also holds. As 
imsic_update_state() completes before aplic_reconfigure_target() (also 
that could be checked in this patch series and is introduced a little 
bit later. Probably I have to re-order some patches again) takes the 
lock, the emulated write either happens before the scan (and gets fixed 
up, or skipped as already correct) or after it (and sees the new location).
Any better option I have now?

~ Oleksii