On 4/5/2023 5:34 PM, Li, Xin3 wrote:
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?
Say there is a case that, a virtual interrupt arrives when an exception
is delivering but hit EPT VIOLATION. The interrupt is pending and
recorded in RVI.
- If KVM re-injects the exception on next VM entry, IDT vectoring first
vectors exception handler and at the instruction boundary (before the
first instruction of exception handler) to deliver the virtual interrupt
(if allowed)
- If KVM doesn't re-inject the exception but relies on the re-execution
of the instruction, then the virtual interrupt can be recognized and
delivered before the instruction causes the exception.
I'm not sure if the order of events matters or not.
