On 16.01.2026 15:25, Oleksii Kurochko wrote: > > 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?
Perhaps the problem is that really I can't see the full picture yet, for the series not putting everything in place that is related. Jan
