2016-09-29 17:41-0400, Paolo Bonzini: >> And a more far-fetched one: if we know that PI.ON is set before vm >> entry, we could just send POSTED_INTR_VECTOR self-IPI after masking >> interrupts and let APICv copy PIR to IRR and deliver interrupts. >> There are two possible drawbacks: Is the self-IPI overhead too big? >> Would APICv IRR evaluation at vm entry take precedence, so we'd have big >> interrupt priority inversion window? > > I don't think there is a risk of inverting interrupt priority, because > that race is always present. But the overhead is probably too much, the > cost of the one xchg in __apic_update_irr is probably half of the whole > IRR update if the PI descriptor cacheline bounces. Yep, I just ran the vmexit kvm-unit-benchmark -- the cpuid and hypercall tests are ~1000 cycles slower if I send the notification self-IPI, which should be far more than PIR->IRR + vmcs_write(RVI, fls(IRR)). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
