From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.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 2367833ADA1 for ; Wed, 18 Feb 2026 23:22:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771456968; cv=none; b=o8wqV4ElUQauuxtt0LxzFkF5Ta1krETq1dsY3wD7206WBLXS4kd+K57MLRNyR0E+ucR4ShtnFJEoDtwCoB7/aba5vVb1iKQ/wstbEz1yEqNhB4k0Gj/JxE4g/3jD17A4DWdq6ND+RRRc7cCDNyOoL98h7sPJt6UOxN333vvBezo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771456968; c=relaxed/simple; bh=ak+Fjrc8c6aDkTgBoI7fd+2k7yh8dnyTxfOcRaoQ/ok=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=UhEPpbhvGi/c7NFQm0jb5bW4l1Gf3yVvowOrq4hWvXMl5XKyZCfbAF65IKzlTZT5f4glzPRfkxkx150p3D/KYLOOXJ3aFlxSB0EEcHIkVqwKkHmU+407RjE21nDWvNYv82DPgmNaTvSRYw1FsSeXcePZSc50KYQGJSSllPMIp8E= 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=OmEFCEVr; arc=none smtp.client-ip=209.85.215.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="OmEFCEVr" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c6fd07933aaso169755a12.0 for ; Wed, 18 Feb 2026 15:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771456965; x=1772061765; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=3oBGE3p/lhKaQkwFweneW6rHkdciCRGmOksHejZJMmw=; b=OmEFCEVrDaO/oYez2gF5z+P+oStD3Owr3qDvDMp16rkyf7MKJ9dZH9yqzfow86Hek7 kLu5bVHuEwrXvzV82LNSipzMdOMyHsc3VUI0jWXA5l/JHoKBK9ze6+uFCtE5sbhKp/3Q myxjzVNH+vPNEyD9YaC5VlLq15fLBKiLTtGcuxfWAHlWzewJSxpRNQvr1HQzqr0TmisU M6SiGz3sIyehWOp4cACokHswIlEm7hCZTvBmI5UddkMduxGYQhalQovS1QlYqgacaeKq X6qQKXfMbQMv0GUtmIl6h91PBwDFXBJADgn7JS7yZqkHXwVZsNRbMallFNk4EybddGGQ 5tCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771456965; x=1772061765; h=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=3oBGE3p/lhKaQkwFweneW6rHkdciCRGmOksHejZJMmw=; b=kb+Q+Frgx2D56/TkpncXlE9Qj1f5FM2jE+Sb4gJAVLmG0DuJ9c337Kuf4DAhmT+W9U y58ogr4jEoNNeRrUrxkvRdcBok+U2NJfSCvFN/UXpqYLVpUujgs72nFSXnQsQTyLRJVF bmYU6uMC1R6OZwP6vLBkmEulO4CaJ2/rCgOUoSb0VQJChrbiYpGJPG0VY9jwKUYdJ6Ot pCyRlxIB9VU2tmNbZIZG9c1dSdL6gRnBQsmc8w0eXyMAzjzRGj1w1XWizclIkhE7/Bxi RwFEZLPQEifdwWhSwjDmTcK5ObRaNzu8sdG2mklF3UAxgw5F0sIXb8bRM23VUluOcjaS SLsQ== X-Forwarded-Encrypted: i=1; AJvYcCUov6B3EXaGricvP7pTEkd2CG2pOHZG/c3dyCULAAQAaj8KNWWOgnGHHFG6hlW2ShFGT9DHPrU6Sj+yg3I=@vger.kernel.org X-Gm-Message-State: AOJu0YzBQx3s7trUyJpQR6Ap1U0VJ7vTtdSxZsxb0WrJ7ImmhXG0KRE3 9ryleUDCXTnaqxyziBFA5cSMCZvGCas1NZVuUig4vn4TFeGKB+ii42b/JhQQf/wO2ThzsshJ7uy YQSyUwg== X-Received: from pgc10.prod.google.com ([2002:a05:6a02:2f8a:b0:b98:d6e8:a405]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:6b0d:b0:394:594c:1ab6 with SMTP id adf61e73a8af0-39512210c2dmr614317637.59.1771456965343; Wed, 18 Feb 2026 15:22:45 -0800 (PST) Date: Wed, 18 Feb 2026 15:22:44 -0800 In-Reply-To: <20260212230751.1871720-2-yosry.ahmed@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260212230751.1871720-1-yosry.ahmed@linux.dev> <20260212230751.1871720-2-yosry.ahmed@linux.dev> Message-ID: Subject: Re: [RFC PATCH 1/5] KVM: nSVM: Do not use L2's RIP for 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="us-ascii" On Thu, Feb 12, 2026, Yosry Ahmed wrote: > For guests with NRIPS disabled, L1 does not provide NextRIP when running > an L2 with an injected soft interrupt, instead it advances L2's RIP > before running it. KVM uses L2's RIP as the NextRIP in vmcb02 to emulate Should "L2's RIP" be "vmcb12's RIP"? The "L2's RIP" terminology gets really confusing in the next paragraph, as NextRIP _is_ L2's (Next)RIP. Hmm, or maybe "current RIP"? I.e. "current RIP" vs. "NextRIP"? > a CPU without NRIPS. > > However, after L2 runs the first time, NextRIP will be updated by the > CPU and/or KVM, and L2's RIP is no longer the correct value to use in > vmcb02. Hence, after save/restore, do not use L2's RIP if a nested run > is not pending (i.e. L2 has run at least once), use the NextRIP value. Too many negatives in this last sentence, it can just be (I think): 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 | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > index de90b104a0dd..eebbe00714e3 100644 > --- a/arch/x86/kvm/svm/nested.c > +++ b/arch/x86/kvm/svm/nested.c > @@ -844,14 +844,18 @@ static void nested_vmcb02_prepare_control(struct vcpu_svm *svm, > vmcb02->control.event_inj_err = svm->nested.ctl.event_inj_err; > > /* > - * next_rip is consumed on VMRUN as the return address pushed on 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 emulate > - * what a nrips=0 CPU would do (L1 is responsible for advancing RIP > - * prior to injecting the event). > + * to L1, take it verbatim from vmcb12. > + * > + * If nrips is supported in hardware but not exposed to L1, stuff the > + * actual L2 RIP to emulate what a nrips=0 CPU would do (L1 is > + * 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 KVM, and > + * the value of the L2 RIP from vmcb12 should not be used. > */ > - if (guest_cpu_cap_has(vcpu, X86_FEATURE_NRIPS)) > + if (guest_cpu_cap_has(vcpu, X86_FEATURE_NRIPS) || !svm->nested.nested_run_pending) This is technically wrong since KVM doesn't require NRIPS. Maybe this? 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 = svm->nested.ctl.next_rip; else vmcb02->control.next_rip = vmcb12_rip; } > vmcb02->control.next_rip = svm->nested.ctl.next_rip; > else if (boot_cpu_has(X86_FEATURE_NRIPS)) > vmcb02->control.next_rip = vmcb12_rip; > -- > 2.53.0.273.g2a3d683680-goog >