On 12/12/2011 09:21 PM, Christoffer Dall wrote:
well, if we block, but receive a signal that we want to go back into
userspace for, and then come back but the guest should still be
waiting, then I want that flag set, and I think it's the most logical
control flow. Am I missing something
On Mon, Dec 12, 2011 at 12:44 PM, Avi Kivity a...@redhat.com wrote:
On 12/12/2011 06:20 PM, Christoffer Dall wrote:
+/**
+ * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by
a guest
+ * @vcpu: the vcpu pointer
+ * @run: the kvm_run structure pointer
+ *
On 12/11/2011 12:25 PM, Christoffer Dall wrote:
From: Christoffer Dall cd...@cs.columbia.edu
When the guest executes a WFI instruction the operation is trapped to
KVM, which emulates the instruction in software. There is no correlation
between a guest executing a WFI instruction and actually
On Mon, Dec 12, 2011 at 9:12 AM, Avi Kivity a...@redhat.com wrote:
On 12/11/2011 12:25 PM, Christoffer Dall wrote:
From: Christoffer Dall cd...@cs.columbia.edu
When the guest executes a WFI instruction the operation is trapped to
KVM, which emulates the instruction in software. There is no
On 12/12/2011 06:20 PM, Christoffer Dall wrote:
+/**
+ * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by
a guest
+ * @vcpu:the vcpu pointer
+ * @run: the kvm_run structure pointer
+ *
+ * Simply sets the wait_for_interrupts flag on the vcpu structure,
From: Christoffer Dall cd...@cs.columbia.edu
When the guest executes a WFI instruction the operation is trapped to
KVM, which emulates the instruction in software. There is no correlation
between a guest executing a WFI instruction and actually puttin the
hardware into a low-power mode, since a
