On 02/16/2011 06:51 PM, Marcelo Tosatti wrote:
On Wed, Feb 16, 2011 at 11:01:47AM +0200, Avi Kivity wrote: > On 02/15/2011 10:36 PM, Marcelo Tosatti wrote: > >On Mon, Feb 14, 2011 at 04:42:16PM +0200, Avi Kivity wrote: > >> Short-circuit an STI; HLT sequence while an interrupt is pending: > >> instead of halting, re-entering the guest, and exiting immediately > >> on an interrupt window exit, go directly to the last step. > >> > >> Saves a vmexit on workloads where interrupts are received synchronously; > >> an example is a disk backed by the host page cache where there is no > >> latency (from the guest's point of view) between the request and fulfilment. > >> > >> Signed-off-by: Avi Kivity<avi@xxxxxxxxxx> > >> --- > >> arch/x86/kvm/vmx.c | 9 +++++++++ > >> 1 files changed, 9 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > >> index ee1cd1a..541da0e 100644 > >> --- a/arch/x86/kvm/vmx.c > >> +++ b/arch/x86/kvm/vmx.c > >> @@ -3437,6 +3437,15 @@ static int handle_interrupt_window(struct kvm_vcpu *vcpu) > >> static int handle_halt(struct kvm_vcpu *vcpu) > >> { > >> skip_emulated_instruction(vcpu); > >> + /* > >> + * Short-circuit an STI; HLT sequence while an interrupt is pending: > >> + * instead of halting, re-entering the guest, and exiting immediately > >> + * on an interrupt window exit, go directly to the last step. > >> + */ > >> + if ((to_vmx(vcpu)->cpu_based_vm_exec_control > >> + & CPU_BASED_VIRTUAL_INTR_PENDING) > >> + && (kvm_get_rflags(vcpu)& X86_EFLAGS_IF)) > >> + return handle_interrupt_window(vcpu); > >> return kvm_emulate_halt(vcpu); > >> } > > > >Why does the normal vcpu entry path fails to inject the interrupt? Because after halt, > >KVM_REQ_EVENT is not set? > > Yes. Also, we want to clear CPU_BASED_VIRTUAL_INTR_PENDING. Is there a reason why it cannot be handled in the main loop?
Don't follow. What are you suggesting? -- error compiling committee.c: too many arguments to function -- 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