Re: [PATCH 5/8] KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction

From: Maciej S. Szmigiero
Date: Mon Apr 04 2022 - 17:27:46 EST

On 4.04.2022 21:33, Sean Christopherson wrote:
On Mon, Apr 04, 2022, Maciej S. Szmigiero wrote:
index 47e7427d0395..a770a1c7ddd2 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -230,8 +230,8 @@ struct vcpu_svm {
bool nmi_singlestep;
u64 nmi_singlestep_guest_rflags;
- unsigned int3_injected;
- unsigned long int3_rip;
+ unsigned soft_int_injected;
+ unsigned long soft_int_linear_rip;
/* optional nested SVM features that are enabled for this guest */
bool nrips_enabled : 1;

I mostly agree with this patch, but think that it doesn't address the
original issue that Maciej wanted to address:

Suppose that there is *no* instruction in L2 code which caused the software
exception, but rather L1 set arbitrary next_rip, and set EVENTINJ to software
exception with some vector, and that injection got interrupted.

I don't think that this code will support this.

Argh, you're right. Maciej's selftest injects without an instruction, but it doesn't
configure the scenario where that injection fails due to an exception+VM-Exit that
isn't intercepted by L1 and is handled by L0. The event_inj test gets the coverage
for the latter, but always has a backing instruction.

Still reviewing the whole patch set, but want to clear this point quickly:
The selftest does have an implicit intervening NPF (handled by L0) while
injecting the first L1 -> L2 event.

I'll do some debug to figure out why the test passes for me. I'm guessing I either
got lucky, e.g. IDT was faulted in already, or I screwed up and the test doesn't
actually pass.

Try applying Maxim's proposed change to this test (adding two additional ud2s at the
start of L2 guest code and adjusting just the next_rip field accordingly).

We might have been lucky in the patched KVM code and have next_rip = rip at this
re-injection case now (the next_rip field was zero in the original KVM code).