Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 1/7/26 5:28 PM, Jan Beulich wrote:
> > +
> > +    /*
> > +     * VCPU interrupts
> > +     *
> > +     * We have a lockless approach for tracking pending VCPU interrupts
> > +     * implemented using atomic bitops. The irqs_pending bitmap represent
> > +     * pending interrupts whereas irqs_pending_mask represent bits changed
> > +     * in irqs_pending.
> And hence a set immediately followed by an unset is then indistinguishable
> from just an unset (or the other way around). This may not be a problem, but
> if it isn't, I think this needs explaining.
I am still not sure that this is actually a problem, or what kind of explanation
is needed.
|unset| is called only when the guest makes such a request, and the guest will
make that request only after it has received an interrupt that was previously
set in the|irq_pending| bitmap and then flushed to the hardware HVIP.

If an interrupt is simply set and then unset without ever being flushed to the
hardware HVIP, it seems there would be no issue, since it would not affect the
guest. However, the question of why this happened at all would still remain.

Do I miss some corner cases which should be taken into account?
Should I still have to add some extra explanation to the comment or commit
message?

~ Oleksii