From: "Maciej S. Szmigiero" <[email protected]>
There are some issues with respect to nSVM L1 -> L2 event injection.
First, the next_rip field of a VMCB is *not* an output-only field for a VMRUN.
This field value (instead of the saved guest RIP) in used by the CPU for
the return address pushed on stack when injecting a software interrupt or
INT3 or INTO exception (this was confirmed by AMD).
On a VMRUN that does event injection it has similar function as VMX's
VM_ENTRY_INSTRUCTION_LEN field, although, in contrast to VMX, it holds an
absolute RIP value, not a relative increment.
However, KVM seems to treat this field as a unidirectional hint from the CPU
to the hypervisor - there seems to be no specific effort to maintain this
field consistency for such VMRUN.
This is mostly visible with running a nested guest, with L1 trying to inject
an event into its L2.
In this case, we need to make sure the next_rip field gets synced from
vmcb12 to vmcb02.
Another issue is that pending L1 -> L2 events are forgotten if there is an
intervening L0 VMEXIT during their delivery.
We need to make sure they are remembered (including their desired next_rip
field value) until they are either re-injected into L2 successfully or
returned back to L1 in the EXITINTINFO field upon a nested VMEXIT.
A new KVM self-test that checks for the nSVM issues described above is
included in this patch series.
These issues are SVM-specific - all the use cases described above already
work correctly with VMX.
This patch set was tested with both Linux and Windows nested guests.
KVM: nSVM: Sync next_rip field from vmcb12 to vmcb02
KVM: SVM: Downgrade BUG_ON() to WARN_ON() in svm_inject_irq()
KVM: nSVM: Don't forget about L1-injected events
KVM: nSVM: Restore next_rip when doing L1 -> L2 event re-injection
KVM: selftests: nSVM: Add svm_nested_soft_inject_test
arch/x86/kvm/svm/nested.c | 69 +++++++-
arch/x86/kvm/svm/svm.c | 60 ++++++-
arch/x86/kvm/svm/svm.h | 48 ++++++
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/include/x86_64/svm_util.h | 2 +
.../kvm/x86_64/svm_nested_soft_inject_test.c | 147 ++++++++++++++++++
7 files changed, 324 insertions(+), 4 deletions(-)
create mode 100644 tools/testing/selftests/kvm/x86_64/svm_nested_soft_inject_test.c
From: "Maciej S. Szmigiero" <[email protected]>
There is no need to bring down the whole host just because there might be
some issue with respect to guest GIF handling in KVM.
Signed-off-by: Maciej S. Szmigiero <[email protected]>
---
arch/x86/kvm/svm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index b069493ad5c7..1e5d904aeec3 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3322,7 +3322,7 @@ static void svm_inject_irq(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
- BUG_ON(!(gif_set(svm)));
+ WARN_ON(!gif_set(svm));
trace_kvm_inj_virq(vcpu->arch.interrupt.nr);
++vcpu->stat.irq_injections;
From: "Maciej S. Szmigiero" <[email protected]>
According to APM 15.7.1 "State Saved on Exit" the next_rip field can be
zero after a VMEXIT in some cases.
Yet, it is used by the CPU for the return address pushed on stack when
injecting INT3 or INTO exception or a software interrupt.
Restore this field to the L1-provided value if zeroed by the CPU when
re-injecting a L1-provided event into L2.
Signed-off-by: Maciej S. Szmigiero <[email protected]>
---
arch/x86/kvm/svm/svm.c | 43 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 5b128baa5e57..760dd0e070ea 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -385,6 +385,44 @@ static int svm_skip_emulated_instruction(struct kvm_vcpu *vcpu)
return 1;
}
+/*
+ * According to APM 15.7.1 "State Saved on Exit" the next_rip field can
+ * be zero after a VMEXIT in some cases.
+ * Yet, it is used by the CPU for the return address pushed on stack when
+ * injecting INT3 or INTO exception or a software interrupt.
+ *
+ * Restore this field to the L1-provided value if zeroed by the CPU when
+ * re-injecting a L1-provided event into L2.
+ */
+static void maybe_fixup_next_rip(struct kvm_vcpu *vcpu, bool uses_err)
+{
+ struct vcpu_svm *svm = to_svm(vcpu);
+ u32 err_vmcb = uses_err ? svm->vmcb->control.event_inj_err : 0;
+ u32 err_inject = uses_err ? svm->nested.ctl.event_inj_err : 0;
+
+ /* No nRIP Save feature? Then nothing to fix up. */
+ if (!nrips)
+ return;
+
+ /* The fix only applies to event injection into a L2. */
+ if (!is_guest_mode(vcpu))
+ return;
+
+ /*
+ * If the current next_rip field is already non-zero assume the CPU had
+ * returned the correct address during the last VMEXIT.
+ */
+ if (svm->vmcb->control.next_rip)
+ return;
+
+ /* Is this a L1 -> L2 event re-injection? */
+ if (!event_inj_same(svm->vmcb->control.event_inj, err_vmcb,
+ svm->nested.ctl.event_inj, err_inject))
+ return;
+
+ svm->vmcb->control.next_rip = svm->nested.ctl.next_rip;
+}
+
static void svm_queue_exception(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
@@ -415,6 +453,9 @@ static void svm_queue_exception(struct kvm_vcpu *vcpu)
| (has_error_code ? SVM_EVTINJ_VALID_ERR : 0)
| SVM_EVTINJ_TYPE_EXEPT;
svm->vmcb->control.event_inj_err = error_code;
+
+ if (kvm_exception_is_soft(nr))
+ maybe_fixup_next_rip(vcpu, true);
}
static void svm_init_erratum_383(void)
@@ -3331,6 +3372,8 @@ static void svm_inject_irq(struct kvm_vcpu *vcpu)
SVM_EVTINJ_VALID;
if (vcpu->arch.interrupt.soft) {
svm->vmcb->control.event_inj |= SVM_EVTINJ_TYPE_SOFT;
+
+ maybe_fixup_next_rip(vcpu, false);
} else {
svm->vmcb->control.event_inj |= SVM_EVTINJ_TYPE_INTR;
}
On Thu, 2022-03-10 at 22:38 +0100, Maciej S. Szmigiero wrote:
> From: "Maciej S. Szmigiero" <[email protected]>
>
> There is no need to bring down the whole host just because there might be
> some issue with respect to guest GIF handling in KVM.
>
> Signed-off-by: Maciej S. Szmigiero <[email protected]>
> ---
> arch/x86/kvm/svm/svm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index b069493ad5c7..1e5d904aeec3 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -3322,7 +3322,7 @@ static void svm_inject_irq(struct kvm_vcpu *vcpu)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
>
> - BUG_ON(!(gif_set(svm)));
> + WARN_ON(!gif_set(svm));
>
> trace_kvm_inj_virq(vcpu->arch.interrupt.nr);
> ++vcpu->stat.irq_injections;
>
Reviewed-by: Maxim Levitsky <[email protected]>
Best regards,
Maxim Levitsky