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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 9/12/26 10:50 AM, SeungJu Cheon wrote:
> On Thu, Sep 10, 2026 at 04:24:06PM +0200, Oleksii Kurochko wrote:
> [...]
> > 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?
> Unless I am missing something, the snapshot also needs to handle the
> case where the target vCPU has not been attached yet:
> vcpu_guest_file_id() returns zero until the vCPU has gone through
> imsic_vsfile_attach(), i.e. until it is scheduled for the first time,
> and vsfile_cpu is NR_CPUS until then.
>
> With the current code, a write targeting such a vCPU makes
> aplic_msi_target_gen() program Guest Index 0 into the physical APLIC
> target register. According to AIA section 4.5.16, Guest Index 0 selects
> the hart's supervisor-level interrupt file rather than a VS-level guest
> interrupt file. Could this cause the MSI to be delivered to Xen's own
> interrupt file with the EIID supplied by the guest?
>
> I also could not find where such a target would be updated once the
> VS-file is attached. imsic_migrate_vcpu() reprograms the relevant
> targets during migration, but the initial imsic_vsfile_attach() path
> does not appear to replay targets which were written before the
> attachment.
>
> Whether a write targeting an unattached vCPU should be supported seems
> like a separate question. Independently of that choice, would it make
> sense to avoid programming the physical TARGET register while
> guest_file_id is zero? The virtual target could either be rejected, or
> retained in the shadow target[] and programmed once the VS-file is
> attached.
If the target vCPU hasn't attached yet it means that 
continue_to_new_vcpu() for it wasn't called so it will be rejected by 
target register emulated code:
...
            target_vcpu = domain_vcpu(currd, guest_hart_idx);

            if ( !target_vcpu )
            {
                gdprintk(XENLOG_ERR, "Invalid vCPU id in target 
register\n");
                /* Ignore such writings */
                return true;
            }
...

(probably we should back to this question in v3 of this patch as several 
things were updated and some of your concerns mentioned here looks to me 
not really possible)
Thanks.

~ Oleksii