KVM: Call kvm_arch_vcpu_blocking early into the blocking sequence
authorMarc Zyngier <maz@kernel.org>
Fri, 2 Aug 2019 10:37:09 +0000 (11:37 +0100)
committerMarc Zyngier <maz@kernel.org>
Sun, 18 Aug 2019 17:50:44 +0000 (18:50 +0100)
commit07ab0f8d9a129add914aff3e988da4033471dfc0
tree4cd843fb35c7ceae08922bad7a4e9a2ea640cca7
parent0ed5f5d63963673ccdd00d101637bf56e6d3d6dc
KVM: Call kvm_arch_vcpu_blocking early into the blocking sequence

When a vpcu is about to block by calling kvm_vcpu_block, we call
back into the arch code to allow any form of synchronization that
may be required at this point (SVN stops the AVIC, ARM synchronises
the VMCR and enables GICv4 doorbells). But this synchronization
comes in quite late, as we've potentially waited for halt_poll_ns
to expire.

Instead, let's move kvm_arch_vcpu_blocking() to the beginning of
kvm_vcpu_block(), which on ARM has several benefits:

- VMCR gets synchronised early, meaning that any interrupt delivered
  during the polling window will be evaluated with the correct guest
  PMR
- GICv4 doorbells are enabled, which means that any guest interrupt
  directly injected during that window will be immediately recognised

Tang Nianyao ran some tests on a GICv4 machine to evaluate such
change, and reported up to a 10% improvement for netperf:

<quote>
netperf result:
D06 as server, intel 8180 server as client
with change:
package 512 bytes - 5500 Mbits/s
package 64 bytes - 760 Mbits/s
without change:
package 512 bytes - 5000 Mbits/s
package 64 bytes - 710 Mbits/s
</quote>

Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
virt/kvm/kvm_main.c