How KVM handle physical interrupt?

5
votes

i am working on KVM optimization for VMs' IO. I have read the KVM codes, usually all the physical interrupt will cause the VMexit and enter into KVM. Then the host's IDT will handle the corresponding physical interrupt. My question is that how KVM decide whether to inject a virtual interrupt into the guest or not? and under what situation it will inject a virtual interrupt to the guest?

Thanks

2
interruptkvm

2 Answers

3
votes

In the Documentation of kvm this is what is told about when the virtual interupt can be injected . Heres the link http://os1a.cs.columbia.edu/lxr/source/Documentation/kvm/api.txt
look at line number 905.
The struct kvm_run structure i think gives control to the application on how it makes the VM behave.Use cscope and search for the string request_interrupt_window in the source code, You will understand how the kvm see when to enter the guest for injecting an interupt.Also go through the api.txt file it is very helpful.

Cheers

EDITED
Here's, one example of the host injecting interupts into the guest.
Assume that there was a page fault in the GUEST VM

  • this causes a VMEXIT
  • Hypervisor/KVM handles the VMEXIT
  • Its sees the reason for VMEXIT through VMCS control structure and find that there was page fault.
  • The host/KVM is responsible for memory virtualization, so it check to see if the page fault was caused
    • because the page was not allocated to the GUEST in which case it calls alloc_page in the HOST kernel and does a VMENTRY to resume GUEST execution.
    • Or the mapping was removed by the GUEST OS, in this case the KVM uses a VMCS control structure as a communication medium to inject a virtual interupt no 14 which causes the GUEST kernel to handle page fault.

This is one example of the host inserting virtual interupt. Ofcourse there are plenty of other ways/reasons to do so.
You can infact configure the VMCS to make the guest do a VMEXIT after executing EVERY INSTRUCTION this can be done using the MONITOR TRAP FLAG.

1
votes

I guess you refer to assigned device interrupts (and not emulated interrupts or virt-IO interrupts which are not directly forwarded from the physical device to the guest). For each irq of the assigned device, request_threaded_irq is called and registers kvm_assigned_dev_thread to be called upon every interrupt. As you can see kvm_set_irq is then called, and as described the only coalescing that takes place if the interrupt is masked. In x86 interrupts can be masked by rflags.if, mov-SS, due to TPR that does not allow the interrupt to be delivered or due to interrupt in service with higher priority. KVM is bound to follow the architecture definition in order not to surprise the guest.