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 6689731985E for ; Mon, 23 Feb 2026 16:59:38 +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=1771865979; cv=none; b=fQdxwxzf+lTU6QkLCCnMsCl+yNhyxJfH/g9m9aHRqJuD+yaY0XRyBQ7KFjuw5YypIX/jtd7PZAiHBT3XU3T0ccODG/PKpVqNzAqiUS7fGSb67G5Bmjb8SfsIwombaOTTvkT+q824j1XHVi5J5XWn2BbSPPZecR/zQeRpAsxRils= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771865979; c=relaxed/simple; bh=+dsoE7weZlfxZS1dnelJZwlS6ZQeOrbFErLKEQkTXX0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=CspIY1BI3HlYyv2JLOFGCKdh6RsB+qkRQHo3KrWWIiADhVJZ0TGXcIxG3zPo/P2BRnLT58FyB9tup433uqKwxWE4oLXe5LoVFVPE5zOvSA2/rV6snvC4UMe9Mp8fLvUfh+tq91yzwIQMU1sQ76TnTBLZJ3ZJbxYTrmtd+JVQjcA= 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=DyWJVd01; 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="DyWJVd01" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ad4a8c1f5aso33868415ad.0 for ; Mon, 23 Feb 2026 08:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771865978; x=1772470778; 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=cFcdxHavVfrpwI540piZzgBIy8xP7SV6WzTjsn6ue8w=; b=DyWJVd01HptGiu5LhtwqeFo5vPP0oov55oeT/M4K0+OxmMKyvkuq3Pq5lcIcgw2JJu HvZwVtx8psKxnwYEHHokKI9SVtWj/Ntii85G6Lu4O/zSR4RbCIeBApDjFRJhH4JVg3O3 bmjIsfDV6Xba8iiNiF3ep21Y//Tqs4CtRZ+vzwu/I9sstOv+TFajABbPZwxtCgJFCoJL gw5kIuA1lwbZFkqCQ+sGH5WqHcFfrE0hcT6fXzzorM6WepDq227afeoRSCM+GLewKtYM CVfTavCcIhNaZ5EVPd3j9t5Ev9pDZbN0TrHELnh0eV8sTwSOxR0As7EZKa9Cm4jqGuLZ +K7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771865978; x=1772470778; 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=cFcdxHavVfrpwI540piZzgBIy8xP7SV6WzTjsn6ue8w=; b=bvUnHE02Q1Kw4gNKRgUADfwmClwV6yXz9+acpo1OxuU1hg4I7LphL+tUghDaQJA6yN Kea2T0+C25luM5D9bcHz9OoDISBR+kitqVZLbfZrv85KACGekhchldIVXdzVUbBpRkYY PePcFEbaF+r9DL2RMOF00BDpqV8nzpAD9Zr1FElaHiqOkY24mxf4NYALWl6SNe+xda9X oAcrMs9Xl/TvtAb2lFzVu9CDBzQIgTkYu7T1g8Qj/eoFxRYr6DRppo94PDPMrhiPlvK0 qeU6cRbOkeGu4dpu+zSQw6h08gmujReRtZ0DiNTNBBfpt87P5F035RmYRrxghNuV/QlW Pysg== X-Forwarded-Encrypted: i=1; AJvYcCXeSqF3/Rq5YS/8c3PoFonE/+AjEv+tQ2+T9O9ZtXDtDk+bUPoOPe5RkbWE9fZ4ZUcEjYuFkNC2dbeKv10=@vger.kernel.org X-Gm-Message-State: AOJu0Yxk1iwKkVdO2jp28LbzDoXgbf4NHArkAYWE/yXlKGkgKch5N9eW GKZDJoBblak5OkdFR5GtvsClbr3Fq9NXcCeOAZ2cLBqtGHYuuTTGHg015EZmOUwaJfxHpRIrQfy QCVy3DA== X-Received: from plsu2.prod.google.com ([2002:a17:902:bf42:b0:2aa:d1fe:fa78]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ce0a:b0:2a7:c188:bd1b with SMTP id d9443c01a7336-2ad742e44efmr89226295ad.25.1771865977618; Mon, 23 Feb 2026 08:59:37 -0800 (PST) Date: Mon, 23 Feb 2026 08:59:36 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <4g25s35ty23lx2je4aknn6dg4ohviqhkbvvel4wkc4chhgp6af@kbqz3lnezo3j> Message-ID: Subject: Re: [PATCH 1/4] KVM: nSVM: Sync next_rip to cached vmcb12 after VMRUN of L2 From: Sean Christopherson To: Yosry Ahmed Cc: Yosry Ahmed , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Sat, Feb 21, 2026, Yosry Ahmed wrote: > [..] > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > > > index de90b104a0dd..0a73dd8f9163 100644 > > > --- a/arch/x86/kvm/svm/nested.c > > > +++ b/arch/x86/kvm/svm/nested.c > > > @@ -1343,10 +1343,17 @@ static void nested_svm_triple_fault(struct kvm_vcpu *vcpu) > > > nested_svm_simple_vmexit(to_svm(vcpu), SVM_EXIT_SHUTDOWN); > > > } > > > > > > +static const struct vmcb_ctrl_area_cached *svm_cached_vmcb12_control(struct vcpu_svm *svm) { > > > + return &svm->nested.ctl; > > > +} > > > > ... > > > > > Is this sufficient? > > > > It's certainly better, but unless a sea of helpers is orders of magnitude worse, > > I would prefer to make it even harder to put hole in our foot. > > > > E.g. unless we're hyper diligent about constifying everything, it's not _that_ > > hard to imagine a chain of events where we end up with a "live" pointer to the > > cache. > > > > 1. A helper like __nested_vmcb_check_controls() isn't const, so we cast to strip > > the const. > > I would argue that casting to strip the const is a red flag and this > scenario should have stopped here :P Key word "should" :-) > > > > Oh, good point. In that case, I think it makes sense to add the flag asap, so > > > > that _if_ it turns out that KVM needs to consume a field that isn't currently > > > > saved/restored, we'll at least have a better story for KVM's that save/restore > > > > everything. > > > > > > Not sure I follow. Do you mean start serializing everything and setting > > > the flag ASAP (which IIUC would be after the rework we discussed), > > > > Yep. > > I don't think it matters that much when we start doing this. In all > cases: > > 1. KVM will need to be backward-compatible. > > 2. Any new features that depend on save+restore of those fields will be > a in a new KVM that does the 'full' save+restore (assuming we don't let > people add per-field flags). > > The only scenario that I can think of is if a feature can be enabled at > runtime, and we want to be able to enable it for a running VM after > migrating from an old KVM to a new KVM. Not sure how likely this is. The scenario I'm thinking of is where we belatedly realize we should have been saving+restoring a field for a feature that is already supported, e.g. gpat. If KVM saves+restores everything, then we don't have to come up with a hacky solution for older KVM, because it already provides the desired behavior for the "save", only the "restore" for the older KVM is broken. Does that make sense? It makes sense in my head, but I'm not sure I communicated the idea very well...