From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57FB637D119 for ; Wed, 4 Mar 2026 17:39:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772645996; cv=none; b=HeBqFD0QhSJA/wIgV5J1YyJPcyLe8F5/zIjymGrwKfn99xefddm5HGnHNbeIrRhAD47JII6ZTOS3hwgnrWYYNZ0WNJ43pdifMSKhtNz/VzKvrrqi2dcciNIpno2RXQcvmJSlFLrRK0yhaAPDs2fV+ffmSsX0TVhuuQUzLxi/3ZE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772645996; c=relaxed/simple; bh=HicJF9SU8FYF4bszknF2PfGmVRZgsJHkAtpALLSPT0E=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Rd+/fFWzKdkutMwA1TiVCZcv0wTxZ4fHW7E9MYLS63xvxqFqv837rWth9xC+FC70qypTgczhlYEUO0ST63welKEvopF2rmUqBkOKG6i3gojYvSBfO86vxiitxMw3J17TF4KhLphc6tlOWOV2thLra1tgB3viT41zXHqcN7r7KG4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=WFcDNOY1; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WFcDNOY1" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ae49120e74so35615565ad.3 for ; Wed, 04 Mar 2026 09:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772645994; x=1773250794; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=YCxR0sncGqt5cTtxeCDvL5ukAbWj6/g0krozrw9t2zU=; b=WFcDNOY13QIco85fEIQ3W8+9mCUaxU7IAr04i891qhYXvySuyeRkLH7mWUT183m0pt x79j0ddD/eMTleWfoTpxB2C72PlxypBSrHEz58Y2P5IAxcrB0fzHlaz4pyJOLFz+ELY7 wwEKtXWoZfozKBuolPpFHktDcjowQFprIGLvtb8PYDc3PHTWbrAztBXsk/Vf1oAX9ywV HtJFJrenqXQ7sQ09Ub+z3X8CcsNDacHoSnwARPeMIXOU+lUnxZH4OuDtsRLA/2OzAgm3 8ID8N7UGtURG1MgPYzNE16EJ5MvhxIotwzSLD9y6wt9/Ou8fSsCt866+eQqL97iFWPcz nN4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772645994; x=1773250794; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=YCxR0sncGqt5cTtxeCDvL5ukAbWj6/g0krozrw9t2zU=; b=iVbUZod+Jt1SgKHMm1xqPsNqgT1+suDeFr2kpU5wCJkCEOTS7pKKQNyQr4oTeVNygO B26DZfPBDImqqg1id7pmPITFLGeINNHvcPXyAqnHIS++IkssKUZUrnmcGEpYQFM9FHc0 2DZ2pmsugNV1hTqvK6sX9E+ZM0tiWRvH3DbGSDi/UtdEevW7y1mkGuhV4TdHI5k3aB+s YCHJDPYA5kCzHU+9Usl79UmmNqxQfrPvyMQJ1Aw4zOXHuD2XJeK86a07L7/0fQEkxQCH cqkj8bEVSxeDnoGDqF6zyuoDEKK12PmMSkWZvwSCwbkx/UQYBCURyC1Y+XCs6ZkkApmF 0VYw== X-Forwarded-Encrypted: i=1; AJvYcCWSgaxzbelzbE/b9Ou4HPdyFIxuGZDoYGu/TmkCdO2qsvRzX8HZK85W4+PRBlPjaKF3X3xgThI=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9Z4uDd19L/a5JIhxpL3olZUaPj2a0AQaXG1AUjhnL7nKVtNOv 7ufkXQXPxP/GfP9u6RtMQtdqV1yQtccBjgQTOvLdDAHZNUV5d95t7O2RiMY8lJprqj46raavcMG 131CuGg== X-Received: from plbkh3.prod.google.com ([2002:a17:903:643:b0:2ae:4d78:4c8d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e886:b0:2ae:698d:94a6 with SMTP id d9443c01a7336-2ae6aa054b2mr30306185ad.2.1772645993537; Wed, 04 Mar 2026 09:39:53 -0800 (PST) Date: Wed, 4 Mar 2026 09:39:51 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260225005950.3739782-1-yosry@kernel.org> <20260225005950.3739782-6-yosry@kernel.org> Message-ID: Subject: Re: [PATCH v3 5/8] KVM: nSVM: Always use NextRIP as vmcb02's NextRIP after first L2 VMRUN From: Sean Christopherson To: Yosry Ahmed Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 04, 2026, Yosry Ahmed wrote: > On Tue, Feb 24, 2026 at 5:00=E2=80=AFPM Yosry Ahmed wr= ote: > > > > For guests with NRIPS disabled, L1 does not provide NextRIP when runnin= g > > an L2 with an injected soft interrupt, instead it advances the current = RIP > > before running it. KVM uses the current RIP as the NextRIP in vmcb02 to > > emulate a CPU without NRIPS. > > > > However, after L2 runs the first time, NextRIP will be updated by the > > CPU and/or KVM, and the current RIP is no longer the correct value to > > use in vmcb02. Hence, after save/restore, use the current RIP if and > > only if a nested run is pending, otherwise use NextRIP. > > > > Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM= _SET_NESTED_STATE") > > CC: stable@vger.kernel.org > > Signed-off-by: Yosry Ahmed > > --- > > arch/x86/kvm/svm/nested.c | 25 ++++++++++++++++--------- > > 1 file changed, 16 insertions(+), 9 deletions(-) > > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > > index 9909ff237e5ca..f3ed1bdbe76c9 100644 > > --- a/arch/x86/kvm/svm/nested.c > > +++ b/arch/x86/kvm/svm/nested.c > > @@ -845,17 +845,24 @@ static void nested_vmcb02_prepare_control(struct = vcpu_svm *svm, > > vmcb02->control.event_inj_err =3D svm->nested.ctl.event_i= nj_err; > > > > /* > > - * next_rip is consumed on VMRUN as the return address pushed o= n the > > + * NextRIP is consumed on VMRUN as the return address pushed on= the > > * stack for injected soft exceptions/interrupts. If nrips is = exposed > > - * to L1, take it verbatim from vmcb12. If nrips is supported = in > > - * hardware but not exposed to L1, stuff the actual L2 RIP to e= mulate > > - * what a nrips=3D0 CPU would do (L1 is responsible for advanci= ng RIP > > - * prior to injecting the event). > > + * to L1, take it verbatim from vmcb12. > > + * > > + * If nrips is supported in hardware but not exposed to L1, stu= ff the > > + * actual L2 RIP to emulate what a nrips=3D0 CPU would do (L1 i= s > > + * responsible for advancing RIP prior to injecting the event).= This is > > + * only the case for the first L2 run after VMRUN. After that (= e.g. > > + * during save/restore), NextRIP is updated by the CPU and/or K= VM, and > > + * the value of the L2 RIP from vmcb12 should not be used. > > */ > > - if (guest_cpu_cap_has(vcpu, X86_FEATURE_NRIPS)) > > - vmcb02->control.next_rip =3D svm->nested.ctl.next_ri= p; > > - else if (boot_cpu_has(X86_FEATURE_NRIPS)) > > - vmcb02->control.next_rip =3D vmcb12_rip; > > + if (boot_cpu_has(X86_FEATURE_NRIPS)) { > > + if (guest_cpu_cap_has(vcpu, X86_FEATURE_NRIPS) || > > + !svm->nested.nested_run_pending) > > + vmcb02->control.next_rip =3D svm->nested.ctl= .next_rip; > > + else > > + vmcb02->control.next_rip =3D vmcb12_rip; > > + } >=20 > This should probably also apply to soft_int_next_rip below the context > lines. Otherwise after patch 7 we keep it uninitialized if the guest > doesn't have NRIPs and !nested_run_pending. That's fine though, isn't it? Because in that case, doesn't the soft int h= ave to comein through svm_update_soft_interrupt_rip()? Ugh, no because nSVM migra= tes control.event_inj. IIUC, we want to end up with this? diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index 03b201fe9613..d12647080051 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -925,7 +925,8 @@ static void nested_vmcb02_prepare_control(struct vcpu_s= vm *svm) */ if (is_evtinj_soft(vmcb02->control.event_inj)) { svm->soft_int_injected =3D true; - if (guest_cpu_cap_has(vcpu, X86_FEATURE_NRIPS)) + if (guest_cpu_cap_has(vcpu, X86_FEATURE_NRIPS) || + !svm->nested.nested_run_pending) svm->soft_int_next_rip =3D vmcb12_ctrl->next_rip; }