On 29.07.2022 09:04, Jane Malalane wrote: > @@ -125,6 +130,9 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_xen_hvm_callback) > { > struct pt_regs *old_regs = set_irq_regs(regs); > > + if (xen_percpu_upcall) > + ack_APIC_irq(); > + > inc_irq_stat(irq_hv_callback_count); > > xen_hvm_evtchn_do_upcall(); > @@ -168,6 +176,15 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu) > if (!xen_have_vector_callback) > return 0; > > + if (xen_percpu_upcall) { > + rc = xen_set_upcall_vector(cpu);
>From all I can tell at least for APs this happens before setup_local_apic(). With there being APIC interaction in this operation mode, as seen e.g. in the earlier hunk above, I think this is logically wrong. And it leads to apic_pending_intr_clear() issuing its warning: The vector registration, as an intentional side effect, marks the vector as pending. Unless IRQs were enabled at any point between the registration and the check, there's simply no way for the corresponding IRR bit to be dealt with (by propagating to ISR when the interrupt is delivered, and then being cleared from ISR by EOI). As a note to x86 maintainers: This comment there /* * 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. */ is pretty clearly wrong - with IRQs disabled there's no way for a pending IRR bit to be "unblocked and turned into a ISR" one. And even if IRQs were enabled TPR would still prevent the handling of any bits potentially set in the 16....31 range. Jan