2016-09-27 23:20+0200, Paolo Bonzini: > The difficult one is patch 2. I find the new code easier to follow than > the old one, but it doesn't mean it works. :) The aim is for APICv to > not use KVM_REQ_EVENT at all for interrupts, therefore turning APICv's > weakness (having to look at PIR on every vmentry) into a strength > (because checking PIR.ON is cheaper than processing KVM_REQ_EVENT). Makes sense. Another possible optimization: when delivering an IPI, don't write the vector to PIR, but directly to VIRR. If the guest is not in VMX non-root mode, then vm entry will take care of the injection; in the other case, we'll send POSTED_INTR_VECTOR. It seems that we don't even have to set PI.ON -- SDM doesn't say it is necessary to evaluate pending virtual interrupts after receiving the notification interrupt. If we have to set PI.ON, we can just skip the PIR->VIRR sync as long as the VM doesn't have an assigned device, because we know that PIR is empty. 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? -- 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
