A puzzle on the interrupt disposal of KVM?

A puzzle on the interrupt disposal of KVM?

[Liang YANG]

Does the vmx_inject_irq and vmx_inject_nmi inject all the interrupt
from outer space ?

Then when the interrrupt yielded from hardware is delieved to the QEMU or KVM ?

Anyone can help me,, Thanks in advance!!

-- 
BestRegards.
YangLiang
_____________________________________________
 Master Candidate.
 Department of Computer Science .
 School of Electronics Engineering & Computer Science .
_____________________________________________

Re: A puzzle on the interrupt disposal of KVM?

[Gleb Natapov]

On Tue, Nov 24, 2009 at 08:49:24AM +0800, Liang YANG wrote:
> Does the vmx_inject_irq and vmx_inject_nmi inject all the interrupt
> from outer space ?
> 
> Then when the interrrupt yielded from hardware is delieved to the QEMU or KVM ?
> 
HW interrupts delivered to the host kernel.

--
			Gleb.

Re: A puzzle on the interrupt disposal of KVM?

[Kurt Kiefer]

I've been studying interrupt delivery in KVM myself lately. I hope I  
can explain what I've found, but, as I'm pretty new to this, please  
take my answer with a grain of salt (as I could be wrong). I would  
really appreciate if someone could correct me here if I am wrong or  
provide more details!

Interrupts from the guest might be delivered via the ioctl  
KVM_INTERRUPT only when the KVM kmod can do interrupt routing.  
However, the default setup for KVM these days implements the interrupt  
controller in the kernel, so this ioctl is unused, and thus,  
vmx_inject_irq is not directly triggered from userspace. The call to  
vmx_inject_irq is made upon re-entry to the guest after I.E. the local  
APIC in the kmod flags that it needs service.

To use the example of a PS2 keyboard press, the control flow works  
like this:

1. Userspace writes to appropriate locations as defined by the i8042  
emulator
2. Userspace calls vm ioctl KVM_IRQ_LINE (IRQ=1, Level=1)
3. Control in the kmod eventually makes a call to kvm_apic_set_irq
4. In the local APIC, __apic_accept_irq does a part in setting up the  
need for service
5. Upon guest entry (vcpu_enter_guest), if there is no nmi and  
kvm_apic_has_interrupt, the host will call inject_pending_irq
6. inject_pending_irq calls vmx_inject_irq

In attempting to answer the second part of your question, I realize  
this point isn't 100% clear to me either. It would seem the point at  
which the interrupt is delivered to KVM is always the point at which  
the guest VCPU is entered. Obviously, if you have a multi-cpu setup  
the calls to set up the local apic can be done in parallel to running  
the guest, but interrupt delivery won't happen until the vcpu is re- 
entered. This seems to mean that interrupts are only delivered when  
the guest is scheduled out and back in by the kernel. Is this right,  
guys?

Kurt

On Nov 23, 2009, at 4:49 PM, Liang YANG wrote:

> Does the vmx_inject_irq and vmx_inject_nmi inject all the interrupt
> from outer space ?
>
> Then when the interrrupt yielded from hardware is delieved to the  
> QEMU or KVM ?
>
> Anyone can help me,, Thanks in advance!!
>
> -- 
> BestRegards.
> YangLiang
> _____________________________________________
> Master Candidate.
> Department of Computer Science .
> School of Electronics Engineering & Computer Science .
> _____________________________________________
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A puzzle on the interrupt disposal of KVM?

[Alexander Graf]

On 24.11.2009, at 09:03, Kurt Kiefer wrote:

> I've been studying interrupt delivery in KVM myself lately. I hope I can explain what I've found, but, as I'm pretty new to this, please take my answer with a grain of salt (as I could be wrong). I would really appreciate if someone could correct me here if I am wrong or provide more details!
> 
> Interrupts from the guest might be delivered via the ioctl KVM_INTERRUPT only when the KVM kmod can do interrupt routing. However, the default setup for KVM these days implements the interrupt controller in the kernel, so this ioctl is unused, and thus, vmx_inject_irq is not directly triggered from userspace. The call to vmx_inject_irq is made upon re-entry to the guest after I.E. the local APIC in the kmod flags that it needs service.
> 
> To use the example of a PS2 keyboard press, the control flow works like this:
> 
> 1. Userspace writes to appropriate locations as defined by the i8042 emulator
> 2. Userspace calls vm ioctl KVM_IRQ_LINE (IRQ=1, Level=1)
> 3. Control in the kmod eventually makes a call to kvm_apic_set_irq
> 4. In the local APIC, __apic_accept_irq does a part in setting up the need for service
> 5. Upon guest entry (vcpu_enter_guest), if there is no nmi and kvm_apic_has_interrupt, the host will call inject_pending_irq
> 6. inject_pending_irq calls vmx_inject_irq
> 
> In attempting to answer the second part of your question, I realize this point isn't 100% clear to me either. It would seem the point at which the interrupt is delivered to KVM is always the point at which the guest VCPU is entered. Obviously, if you have a multi-cpu setup the calls to set up the local apic can be done in parallel to running the guest, but interrupt delivery won't happen until the vcpu is re-entered. This seems to mean that interrupts are only delivered when the guest is scheduled out and back in by the kernel. Is this right, guys?

It means that interrupts are delivered on guest entries. That doesn't mean you have to exit the vcpu thread. You can just as well still be in the vcpu run loop.

So if you for example get a #PF in the guest that is trapped by the host because of shadow paging, KVM will check for pending irqs again.

Alex

Re: A puzzle on the interrupt disposal of KVM?

[Liang YANG]

I think Kurt have a clear view on interrupt deliver routine.
Maybe when a outer physical interrupt yield durning the guest running
on cpu, this interrupt cause the guest exit
and eventually delived to the host to be disposed. Is that right ?

Thanks for everybody's reply.

On Tue, Nov 24, 2009 at 4:49 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 24.11.2009, at 09:03, Kurt Kiefer wrote:
>
>> I've been studying interrupt delivery in KVM myself lately. I hope I can explain what I've found, but, as I'm pretty new to this, please take my answer with a grain of salt (as I could be wrong). I would really appreciate if someone could correct me here if I am wrong or provide more details!
>>
>> Interrupts from the guest might be delivered via the ioctl KVM_INTERRUPT only when the KVM kmod can do interrupt routing. However, the default setup for KVM these days implements the interrupt controller in the kernel, so this ioctl is unused, and thus, vmx_inject_irq is not directly triggered from userspace. The call to vmx_inject_irq is made upon re-entry to the guest after I.E. the local APIC in the kmod flags that it needs service.
>>
>> To use the example of a PS2 keyboard press, the control flow works like this:
>>
>> 1. Userspace writes to appropriate locations as defined by the i8042 emulator
>> 2. Userspace calls vm ioctl KVM_IRQ_LINE (IRQ=1, Level=1)
>> 3. Control in the kmod eventually makes a call to kvm_apic_set_irq
>> 4. In the local APIC, __apic_accept_irq does a part in setting up the need for service
>> 5. Upon guest entry (vcpu_enter_guest), if there is no nmi and kvm_apic_has_interrupt, the host will call inject_pending_irq
>> 6. inject_pending_irq calls vmx_inject_irq
>>
>> In attempting to answer the second part of your question, I realize this point isn't 100% clear to me either. It would seem the point at which the interrupt is delivered to KVM is always the point at which the guest VCPU is entered. Obviously, if you have a multi-cpu setup the calls to set up the local apic can be done in parallel to running the guest, but interrupt delivery won't happen until the vcpu is re-entered. This seems to mean that interrupts are only delivered when the guest is scheduled out and back in by the kernel. Is this right, guys?
>
> It means that interrupts are delivered on guest entries. That doesn't mean you have to exit the vcpu thread. You can just as well still be in the vcpu run loop.
>
> So if you for example get a #PF in the guest that is trapped by the host because of shadow paging, KVM will check for pending irqs again.
>
> Alex



-- 
BestRegards.
YangLiang
_____________________________________________
 Master Candidate.
 Department of Computer Science .
 School of Electronics Engineering & Computer Science .
_____________________________________________

Re: A puzzle on the interrupt disposal of KVM?

[Gleb Natapov]

On Thu, Nov 26, 2009 at 03:14:04PM +0800, Liang YANG wrote:
> I think Kurt have a clear view on interrupt deliver routine.
> Maybe when a outer physical interrupt yield durning the guest running
> on cpu, this interrupt cause the guest exit
> and eventually delived to the host to be disposed. Is that right ?
> 
Correct.

> Thanks for everybody's reply.
> 
> On Tue, Nov 24, 2009 at 4:49 PM, Alexander Graf <agraf@suse.de> wrote:
> >
> > On 24.11.2009, at 09:03, Kurt Kiefer wrote:
> >
> >> I've been studying interrupt delivery in KVM myself lately. I hope I can explain what I've found, but, as I'm pretty new to this, please take my answer with a grain of salt (as I could be wrong). I would really appreciate if someone could correct me here if I am wrong or provide more details!
> >>
> >> Interrupts from the guest might be delivered via the ioctl KVM_INTERRUPT only when the KVM kmod can do interrupt routing. However, the default setup for KVM these days implements the interrupt controller in the kernel, so this ioctl is unused, and thus, vmx_inject_irq is not directly triggered from userspace. The call to vmx_inject_irq is made upon re-entry to the guest after I.E. the local APIC in the kmod flags that it needs service.
> >>
> >> To use the example of a PS2 keyboard press, the control flow works like this:
> >>
> >> 1. Userspace writes to appropriate locations as defined by the i8042 emulator
> >> 2. Userspace calls vm ioctl KVM_IRQ_LINE (IRQ=1, Level=1)
> >> 3. Control in the kmod eventually makes a call to kvm_apic_set_irq
> >> 4. In the local APIC, __apic_accept_irq does a part in setting up the need for service
> >> 5. Upon guest entry (vcpu_enter_guest), if there is no nmi and kvm_apic_has_interrupt, the host will call inject_pending_irq
> >> 6. inject_pending_irq calls vmx_inject_irq
> >>
> >> In attempting to answer the second part of your question, I realize this point isn't 100% clear to me either. It would seem the point at which the interrupt is delivered to KVM is always the point at which the guest VCPU is entered. Obviously, if you have a multi-cpu setup the calls to set up the local apic can be done in parallel to running the guest, but interrupt delivery won't happen until the vcpu is re-entered. This seems to mean that interrupts are only delivered when the guest is scheduled out and back in by the kernel. Is this right, guys?
> >
> > It means that interrupts are delivered on guest entries. That doesn't mean you have to exit the vcpu thread. You can just as well still be in the vcpu run loop.
> >
> > So if you for example get a #PF in the guest that is trapped by the host because of shadow paging, KVM will check for pending irqs again.
> >
> > Alex
> 
> 
> 
> -- 
> BestRegards.
> YangLiang
> _____________________________________________
>  Master Candidate.
>  Department of Computer Science .
>  School of Electronics Engineering & Computer Science .
> _____________________________________________
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.