On 18/11/2022 10:31, Jan Beulich wrote: > Linux'es relatively new use of HVMOP_set_evtchn_upcall_vector has > exposed a problem with the marking of the respective vector as > pending: For quite some time Linux has been checking whether any stale > ISR or IRR bits would still be set while preparing the LAPIC for use. > This check is now triggering on the upcall vector, as the registration, > at least for APs, happens before the LAPIC is actually enabled. > > In software-disabled state an LAPIC would not accept any interrupt > requests and hence no IRR bit would newly become set while in this > state. As a result it is also wrong for us to mark the upcall vector as > having a pending request when the vLAPIC is in this state.
I agree with this. > To compensate for the "enabled" check added to the assertion logic, add > logic to (conditionally) mark the upcall vector as having a request > pending at the time the LAPIC is being software-enabled by the guest. But this, I don't think is appropriate. The point of raising on enable is allegedly to work around setup race conditions. I'm unconvinced by this reasoning, but it is what it is, and the stated behaviour is to raise there and then. If a guest enables evtchn while the LAPIC is disabled, then the interrupt is lost. Like every other interrupt in an x86 system. I don't think there is any credible way a guest kernel author can expect the weird evtchn edgecase to wait for an arbitrary point in the future, and it's a corner case that I think is worth not keeping. ~Andrew
