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<a...@redhat.com>
> >> ---
> >> 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?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
