On 02/17/2011 06:16 PM, Marcelo Tosatti wrote:
On Thu, Feb 17, 2011 at 11:12:43AM +0200, Avi Kivity wrote:
> >> >> 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?
That vcpu main loop (inject_pending_events etc) should be able to inject
the interrupt and clear interrupt exiting, instead of a short circuit
in specific exit handlers, as an improvement on top of the current
patchset.
Yes, it makes sense to make move virtual interrupt pending logic into
x86.c. On the other hand, it may conflict with using the hardware
interrupt queue on svm (which we don't make use of yet).
Any numbers, BTW?
Not yet.
--
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
