[lkml]   [2016]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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?

 \ /
  Last update: 2016-09-29 21:56    [W:0.189 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site