On Wed, Apr 5, 2023 at 11:34 AM Li, Xin3 <xin3.li@xxxxxxxxx> wrote: > The question is, must KVM inject a hardware exception from the IDT vectoring > information field? Is there any correctness issue if KVM does not? Fault exceptions probably can be handled as you say, but traps definitely have to be reinjected. For example, not reinjecting a singlestep #DB would cause the guest to miss the exception for that instruction. > 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. (Let's use "second" exception instead of "nested" exception). The CPU doesn't re-trigger the original event unless the second exception causes a vmexit and the hypervisor moves the IDT-vectored event fields to the event injection fields. In this case, the first exception wasn't injected at all. If the second exception does not cause a vmexit, it is handled as usual by the processor (by checking if the two exceptions are benign, contributory or page faults). The behavior is the same even if the first exception comes from VMX event injection. Paolo > 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 >
