I'm looking at reducing the interrupt overhead for virtualized guests: some workloads spend a large part of their time processing interrupts. On kvm, an EOI write from the guest causes an expensive exit to host; we avoid this using shared memory. The patches work fine on my boxes. See individual patches for perf tests. You need to patch qemu to whitelist the kvm feature. qemu patch was sent separately. The patches are against a merge of kvm.git (for apic announce bits) and tip.git master. The last patch in the series, supplying the host part, also depends on the ISR optimization patch that I sent previously: changes to optimization would require reworking this last patch in the series. The rest of the patchset has not changed since v2. Thanks, MST Changes from v4: Turn off PV EOI on each exit. Turn it back on when safe. Suggested by Avi. Address bug with nested interrupts pointed out by Marcelo. Changes from v3: Address review comments by Marcelo: Multiple cosmetic changes eoi -> pv_eoi Added multiple comments Changes from v2: Kill guest with GP on an illegal MSR value Add documentation Changes from v1: Add host side patch to series Remove kvm-specific __test_and_clear_bit, document that x86 one does what we want already Clear msr on cpu unplug Michael S. Tsirkin (5): kvm_para: guest side for eoi avoidance x86/bitops: note on __test_and_clear_bit atomicity kvm: eoi msi documentation kvm: only sync when attention bits set kvm: host side for eoi optimization Documentation/virtual/kvm/msr.txt | 32 +++++++++ arch/x86/include/asm/bitops.h | 13 +++- arch/x86/include/asm/kvm_host.h | 12 +++ arch/x86/include/asm/kvm_para.h | 7 ++ arch/x86/kernel/kvm.c | 51 +++++++++++++- arch/x86/kvm/cpuid.c | 1 + arch/x86/kvm/lapic.c | 135 +++++++++++++++++++++++++++++++++++- arch/x86/kvm/lapic.h | 2 + arch/x86/kvm/trace.h | 34 +++++++++ arch/x86/kvm/x86.c | 8 ++- 10 files changed, 285 insertions(+), 10 deletions(-) -- MST -- 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
