Messages in this thread | | | Date | Thu, 29 Sep 2016 21:55:57 +0200 | From | Radim Krčmář <> | Subject | Re: [RFC PATCH 0/3] kvm: x86: speedups for APICv |
| |
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?
| |