The VMCS IDT vectoring information field is used to report basic information
associated with the event that was being delivered when a VM exit occurred.
such an event itself doesn't trigger a VM exit, however, a condition to deliver
the event is not met, e.g., EPT violation.
When the IDT vectoring information field reports a maskable external interrupt,
KVM reinjects this external interrupt after handling the VM exit. Otherwise,
the external interrupt is lost.
KVM handles a hardware exception reported in the IDT vectoring information
field in the same way, which makes nothing wrong. This piece of code is in
__vmx_complete_interrupts():
case INTR_TYPE_SOFT_EXCEPTION:
vcpu->arch.event_exit_inst_len = vmcs_read32(instr_len_field);
fallthrough;
case INTR_TYPE_HARD_EXCEPTION:
if (idt_vectoring_info & VECTORING_INFO_DELIVER_CODE_MASK) {
u32 err = vmcs_read32(error_code_field);
kvm_requeue_exception_e(vcpu, vector, err);
} else
kvm_requeue_exception(vcpu, vector);
break;
But if KVM just ignores any hardware exception in such a case, the CPU will
re-generate it once it resumes guest execution, which looks cleaner.
The question is, must KVM inject a hardware exception from the IDT vectoring
information field? Is there any correctness issue if KVM does not?
If no correctness issue, it's better to not do it, because the injected event
from IDT vectoring could trigger another exception, i.e., a nested exception,
and after the nested exception is handled, the CPU resumes to re-trigger the
original event, which makes not much sense to inject it.
In addition, the benefits of not doing so are:
1) Less code.
2) Faster execution. Calling kvm_requeue_exception_e()/kvm_requeue_exception()
consumes a few hundred cycles at least, although it's a rare case with EPT,
but a lot with shadow (who cares?). And vmx_inject_exception() also has a
cost.
3) An IDT vectoring could trigger more than one VM exit, e.g., the first is an
EPT violation, and the second a PML full, KVM needs to reinject it twice
(extremely rare).
Thanks!
Xin
