public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: kvm list <kvm@vger.kernel.org>
Cc: virtualization@lists.linux-foundation.org,
	Glauber Costa <glommer@redhat.com>, Avi Kivity <avi@redhat.com>,
	Nick Piggin <npiggin@suse.de>
Subject: [PATCH 3/3] Split the KVM pv-ops support by feature
Date: Wed, 18 Nov 2009 01:13:12 +0100	[thread overview]
Message-ID: <1258503192-14246-4-git-send-email-agraf@suse.de> (raw)
In-Reply-To: <1258503192-14246-1-git-send-email-agraf@suse.de>

Currently selecting KVM guest support enabled multiple features at once that
not everyone necessarily wants to have, namely:

 - PV MMU
 - zero io delay
 - apic detection workaround

Let's split them off so we don't drag in the full pv-ops framework just to
detect we're running on KVM. That gives us more chances to tweak performance!

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/x86/Kconfig      |   29 ++++++++++++++++++++++++++++-
 arch/x86/kernel/kvm.c |   22 +++++++++++++++-------
 2 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8c150b6..97d4f92 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -522,11 +522,38 @@ config KVM_CLOCK
 
 config KVM_GUEST
 	bool "KVM Guest support"
-	select PARAVIRT_ALL
+	select PARAVIRT
 	---help---
 	  This option enables various optimizations for running under the KVM
 	  hypervisor.
 
+config KVM_IODELAY
+	bool "KVM IO-delay support"
+	depends on KVM_GUEST
+	select PARAVIRT_CPU
+	---help---
+	  Usually we wait for PIO access to complete. When inside KVM there's
+	  no need to do that, as we know that we're not going through a bus,
+	  but process PIO requests instantly.
+
+	  This option disables PIO waits, but drags in CPU-bound pv-ops. Thus
+	  you will probably get more speed loss than speedup using this option.
+
+	  If in doubt, say N.
+
+config KVM_MMU
+	bool "KVM PV MMU support"
+	depends on KVM_GUEST
+	select PARAVIRT_MMU
+	---help---
+	  This option enables the paravirtualized MMU for KVM. In most cases
+	  it's pretty useless and shouldn't be used.
+
+	  It will only cost you performance, because it drags in pv-ops for
+	  memory management.
+
+	  If in doubt, say N.
+
 source "arch/x86/lguest/Kconfig"
 
 config PARAVIRT
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 63b0ec8..7e0207f 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -29,6 +29,16 @@
 #include <linux/hardirq.h>
 #include <asm/timer.h>
 
+#ifdef CONFIG_KVM_IODELAY
+/*
+ * No need for any "IO delay" on KVM
+ */
+static void kvm_io_delay(void)
+{
+}
+#endif  /* CONFIG_KVM_IODELAY */
+
+#ifdef CONFIG_KVM_MMU
 #define MMU_QUEUE_SIZE 1024
 
 struct kvm_para_state {
@@ -43,13 +53,6 @@ static struct kvm_para_state *kvm_para_state(void)
 	return &per_cpu(para_state, raw_smp_processor_id());
 }
 
-/*
- * No need for any "IO delay" on KVM
- */
-static void kvm_io_delay(void)
-{
-}
-
 static void kvm_mmu_op(void *buffer, unsigned len)
 {
 	int r;
@@ -194,15 +197,19 @@ static void kvm_leave_lazy_mmu(void)
 	mmu_queue_flush(state);
 	paravirt_leave_lazy_mmu();
 }
+#endif  /* CONFIG_KVM_MMU */
 
 static void __init paravirt_ops_setup(void)
 {
 	pv_info.name = "KVM";
 	pv_info.paravirt_enabled = 1;
 
+#ifdef CONFIG_KVM_IODELAY
 	if (kvm_para_has_feature(KVM_FEATURE_NOP_IO_DELAY))
 		pv_cpu_ops.io_delay = kvm_io_delay;
+#endif
 
+#ifdef CONFIG_KVM_MMU
 	if (kvm_para_has_feature(KVM_FEATURE_MMU_OP)) {
 		pv_mmu_ops.set_pte = kvm_set_pte;
 		pv_mmu_ops.set_pte_at = kvm_set_pte_at;
@@ -226,6 +233,7 @@ static void __init paravirt_ops_setup(void)
 		pv_mmu_ops.lazy_mode.enter = kvm_enter_lazy_mmu;
 		pv_mmu_ops.lazy_mode.leave = kvm_leave_lazy_mmu;
 	}
+#endif  /* CONFIG_KVM_MMU */
 #ifdef CONFIG_X86_IO_APIC
 	no_timer_check = 1;
 #endif
-- 
1.6.0.2


  parent reply	other threads:[~2009-11-18  0:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-18  0:13 [PATCH 0/3] Split up pv-ops Alexander Graf
2009-11-18  0:13 ` [PATCH 1/3] Split paravirt ops by functionality Alexander Graf
2009-11-19 14:59   ` Jeremy Fitzhardinge
2009-11-19 15:21     ` Alexander Graf
2009-11-18  0:13 ` [PATCH 2/3] Only export selected pv-ops feature structs Alexander Graf
2009-11-18  0:13 ` Alexander Graf [this message]
2009-11-18  1:33   ` [PATCH 3/3] Split the KVM pv-ops support by feature Rusty Russell
2009-11-18  1:37     ` Alexander Graf
2009-11-19  7:42 ` [PATCH 0/3] Split up pv-ops Avi Kivity
2009-12-03 14:52 ` Alexander Graf
2009-12-03 15:00   ` Avi Kivity
2009-12-03 15:04     ` Alexander Graf
2009-12-03 15:07       ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1258503192-14246-4-git-send-email-agraf@suse.de \
    --to=agraf@suse.de \
    --cc=avi@redhat.com \
    --cc=glommer@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox