[PATCH/RFC] KVM: Adds support for halting in the kernel

[PATCH/RFC] KVM: Adds support for halting in the kernel

[Gregory Haskins]

  Hi All,

  I was thinking about some of the issues that we are dealing with
  w.r.t. signalling a sleeping userspace (eventfd, signals, etc).  I was
  wondering if perhaps we were looking at the problem the wrong way.  Can we
  perform halts in the kernel and therefore eliminate the need to signal
  userspace all together?  I put together a proof-of-concept patch to try out
  this idea.  This patch replaces the fd-signaling patch previously sent.

  Comments please.

  -Greg

---

 drivers/kvm/kvm.h      |    3 +++
 drivers/kvm/kvm_main.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/kvm/svm.c      |    7 +------
 drivers/kvm/vmx.c      |    7 +------
 4 files changed, 52 insertions(+), 12 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 7ca2608..c5ab863 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -273,6 +273,7 @@ struct kvm_stat {
 	u32 signal_exits;
 	u32 irq_window_exits;
 	u32 halt_exits;
+	u32 halt_wakeup;
 	u32 request_irq_exits;
 	u32 irq_exits;
 	u32 light_exits;
@@ -354,6 +355,7 @@ struct kvm_vcpu_irq {
 	int                  pending;
 	int                  deferred;
 	int                  guest_cpu;
+	wait_queue_head_t    wq;
 };
 
 struct kvm_lapic {
@@ -642,6 +644,7 @@ void kvm_mmu_module_exit(void);
 
 int kvm_apicbus_send(struct kvm *kvm, int dest, int trig_mode, int level,
 		     int dest_mode, int delivery_mode, int vector);
+int kvm_vcpu_halt(struct kvm_vcpu *vcpu);
 
 void kvm_mmu_destroy(struct kvm_vcpu *vcpu);
 int kvm_mmu_create(struct kvm_vcpu *vcpu);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 58cad68..2f346e6 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -69,6 +69,7 @@ static struct kvm_stats_debugfs_item {
 	{ "signal_exits", STAT_OFFSET(signal_exits) },
 	{ "irq_window", STAT_OFFSET(irq_window_exits) },
 	{ "halt_exits", STAT_OFFSET(halt_exits) },
+	{ "halt_wakeup", STAT_OFFSET(halt_wakeup) },
 	{ "request_irq", STAT_OFFSET(request_irq_exits) },
 	{ "irq_exits", STAT_OFFSET(irq_exits) },
 	{ "light_exits", STAT_OFFSET(light_exits) },
@@ -333,6 +334,7 @@ static struct kvm *kvm_create_vm(void)
 		memset(&vcpu->irq, 0, sizeof(vcpu->irq));
 		spin_lock_init(&vcpu->irq.lock);
 		vcpu->irq.deferred = -1;
+		init_waitqueue_head(&vcpu->irq.wq);
 
 		vcpu->cpu = -1;
 		vcpu->kvm = kvm;
@@ -2437,6 +2439,41 @@ out1:
 }
 
 /*
+ * The vCPU has executed a HLT instruction.
+ */
+int kvm_vcpu_halt(struct kvm_vcpu *vcpu)
+{
+	DECLARE_WAITQUEUE(wait, current);
+
+	++vcpu->stat.halt_exits;
+
+	spin_lock_irq(&vcpu->irq.lock);
+	__add_wait_queue(&vcpu->irq.wq, &wait);
+
+	/*
+	 * We will block until either an interrupt or a signal wakes us up
+	 */
+	while(!__kvm_vcpu_irq_all_pending(vcpu) && !signal_pending(current)) {
+		set_current_state(TASK_INTERRUPTIBLE);
+
+		spin_unlock_irq(&vcpu->irq.lock);
+		vcpu_put(vcpu);
+
+		schedule();
+
+		vcpu_load(vcpu);
+		spin_lock_irq(&vcpu->irq.lock);
+	}
+
+	__remove_wait_queue(&vcpu->irq.wq, &wait);
+	__set_current_state(TASK_RUNNING);
+	spin_unlock_irq(&vcpu->irq.lock);
+
+	return 1;
+}
+EXPORT_SYMBOL_GPL(kvm_vcpu_halt);
+
+/*
  * This function is invoked whenever we want to interrupt a vcpu that is
  * currently executing in guest-mode.  It currently is a no-op because
  * the simple delivery of the IPI to execute this function accomplishes our
@@ -2486,6 +2523,16 @@ static void kvm_vcpu_intr(struct kvm_irqsink *this,
 				++vcpu->stat.guest_preempt;
 			}
 		}
+
+		/*
+		 * If the CPU is halted it will be waiting for a wake-up
+		 */
+		if (waitqueue_active(&vcpu->irq.wq)) {
+			wake_up_interruptible_sync(&vcpu->irq.wq);
+			set_tsk_need_resched(current);
+			++vcpu->stat.halt_wakeup;
+		}
+	
 	} else
 		++vcpu->stat.irq_ignored;
 
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 78b9f8f..7727a6b 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1098,12 +1098,7 @@ static int halt_interception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 {
 	vcpu->svm->next_rip = vcpu->svm->vmcb->save.rip + 1;
 	skip_emulated_instruction(vcpu);
-	if (kvm_vcpu_irq_pending(vcpu))
-		return 1;
-
-	kvm_run->exit_reason = KVM_EXIT_HLT;
-	++vcpu->stat.halt_exits;
-	return 0;
+	return kvm_vcpu_halt(vcpu);
 }
 
 static int vmmcall_interception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 8cfadaf..44e8bf7 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -1968,12 +1968,7 @@ static int handle_interrupt_window(struct kvm_vcpu *vcpu,
 static int handle_halt(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 {
 	skip_emulated_instruction(vcpu);
-	if (kvm_vcpu_irq_pending(vcpu))
-		return 1;
-
-	kvm_run->exit_reason = KVM_EXIT_HLT;
-	++vcpu->stat.halt_exits;
-	return 0;
+	return kvm_vcpu_halt(vcpu);
 }
 
 static int handle_vmcall(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [PATCH/RFC] KVM: Adds support for halting in the kernel

[Avi Kivity]

Gregory Haskins wrote:
>   Hi All,
>
>   I was thinking about some of the issues that we are dealing with
>   w.r.t. signalling a sleeping userspace (eventfd, signals, etc).  I was
>   wondering if perhaps we were looking at the problem the wrong way.  Can we
>   perform halts in the kernel and therefore eliminate the need to signal
>   userspace all together?  I put together a proof-of-concept patch to try out
>   this idea.  This patch replaces the fd-signaling patch previously sent.
>
>   Comments please.
>   

This is a winner.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [PATCH/RFC] KVM: Adds support for halting in the kernel

[Carsten Otte]

Gregory Haskins wrote:
>   I was thinking about some of the issues that we are dealing with
>   w.r.t. signalling a sleeping userspace (eventfd, signals, etc).  I was
>   wondering if perhaps we were looking at the problem the wrong way.  Can we
>   perform halts in the kernel and therefore eliminate the need to signal
>   userspace all together?  I put together a proof-of-concept patch to try out
>   this idea.  This patch replaces the fd-signaling patch previously sent.
 >
 >   Comments please.
This pretty much looks like where we're heading on 390. We'll also go 
for a wait queue. Thumbs up.

so long,
Carsten

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/