x86/HVM: Linux'es apic_pending_intr_clear() warns about stale IRR

[Jan Beulich <jbeulich@xxxxxxxx>]

Hello,

quite likely this isn't new, but I've ended up noticing it only recently:
On an oldish system where I hand a HVM guest an SR-IOV NIC (not sure yet
whether that actually matters) all APs have that warning issued, with all
reported values zero except for the very first IRR one - that's 00080000.
Which is suspicious by itself, for naming vector 0x13, i.e. below 0x20
and hence within CPU exception range.

For one I wonder about their logic: The function is called after setting
TPR to 0x10, which prevents the handling of vectors below 0x20 (and in
particular their propagation from ISR to IRR, if my understanding of the
process is right and the convoluted and imo partly incomplete SDM
description hasn't confused me). Plus the function runs when IRQs are
still off, which is another reason why nothing would ever propagate from
IRR to ISR while the function performs it work. Yet a comment there says

        /*
         * If the ISR map is not empty. ACK the APIC and run another round
         * to verify whether a pending IRR has been unblocked and turned
         * into a ISR.
         */

suggesting IRR bits could "promote" to ISR ones. And this, to me, is the
only justification for warning about leftover IRR bits (whereas I
certainly agree that the logic should result in all clear ISR bits, and
hence warning when one is still set is appropriate).

And then I got puzzled by our logic: vlapic_get_ppr() is called only by
vlapic_set_ppr(), vlapic_lowest_prio(), and vlapic_read_aligned(). Yet
in particular not by vlapic_has_pending_irq(). While it looks like we
don't really ignore TPR during delivery, this appears to be a strange
split approach: hvm_interrupt_blocked() checks TPR, whereas
vlapic_has_pending_irq() checks ISR. I wonder if subtle issues can't
result from that ...

Of course I'm yet to figure out how IRR bit 0x13 ends up being set in
the first place.

Any correction to my understanding as well as any useful insight would
be appreciated.

Jan