Re: The necessity of injecting a hardware exception reported in VMX IDT vectoring information

[Sean Christopherson <seanjc@google.com>]

On Fri, Apr 07, 2023, Xiaoyao Li wrote:
> 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.

It matters, e.g. if the exception occurs in an STI shadow then I believe the vIRQ
would get incorrectly delivered in the STI shadow.  That'll likely happen anyways
after the resulting IRET, but there's no guarantee the guest's exception handler
will IRET, or that it will even run, e.g. guest might triple fault first.