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 1F58337754D for ; Mon, 23 Feb 2026 20:24:01 +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=1771878243; cv=none; b=s2rCeXJlbFdcwYCutICy2hOL8zUIdqTCl9gSgj5pfN88Sd/NdieVK4CUHoraolN/glbwWnGfrhQ+lY8sBJX3a1lCVmnDpwEid8oB2xokFHa1AfWqrsysFYXGoK4ZB2sPbhE8vz5wFhMEccH2UOgedynw46ZSDQ/Z0AmHjn2QO/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771878243; c=relaxed/simple; bh=pSFoekhb79w/9Q6oqn583+qO2wXFWypE1LjbHB7K14k=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=tAk/cb4KpMtKDViXytBNTayiOc/dCZ66r7sqMkwk9bbQE6TZcTQ9BTKmdrG938UmNYpT+z58Hdej0cTQ+FmZv5sC2M53aR+rPims48gEZduEEzXfDMQIP7rhW/FG3HNTrKhygE/S0KDKhdvBJesD1cM8fz0h/JPMSSsv6+1GIhU= 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=ufi05Hr5; 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="ufi05Hr5" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c6e18b8fe1eso3546327a12.1 for ; Mon, 23 Feb 2026 12:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771878241; x=1772483041; 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=GD99/y0vYgITqywbHvEch3hhxD8ZoR8xSwqLHAkhMgQ=; b=ufi05Hr54980tzktMyleYB9zBLpL0uVSokSQ9EPTNzmtpMfyuuIHlarzuXhO041krD ufHR/HtHACxJo6w04FbFnNuqz7ni4UJelO3ih5p1ArcgqAnMB2qKPch3ACTpbrWyU3vH tYI9ilgqKfxjP4+IOoWY4wdgOGf2PIdtScGsyxoUmK+Ws4fa8Q+FEFdD8vnB4EaRlwNQ 51WcEkFGqk01T9HJcAvsFEgfay87uuUCs4Ie8hdjHV65SfdKwlvzMttx8j60Jf0MK/uh k42jjlNeg5gyleKl88pRaM9JYBkt6NpjUB43OlJQtFVh5bkjULo+1gVIMlbUYc6mP2yy Kn3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771878241; x=1772483041; 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=GD99/y0vYgITqywbHvEch3hhxD8ZoR8xSwqLHAkhMgQ=; b=nYQoEFdcbrIZ//JeezULsPh8mCnaXiqjTOFrLymZ5OsuuVNPDL2IORg1K3olYke2zO VsJqZsEYeO1QGG2pAZaxMwK5C8pJXH3aS9geE93xiEPG7tFMjeUgjylTTaDNQ/C2HD7/ MfbD9dwgWMI12TeGR5ZSRsJEMmRMTE30wDxGlb4Awmeq0EgkSpbBmVkpMGekqZAwdSqY ri48BOGB6DXFtyiykt3i5hd+et9AgYnBreAbkNQDt9MowNeSQA4mtnGVCVU01DrxnoE9 md2K8Cufbe0OSWiSf7fGUsduJb0hDa0BskXPsRGKgJDJ1tfWxoud5qiz1ISuXWxoo4Ua 9uiw== X-Forwarded-Encrypted: i=1; AJvYcCV1lrTPlPq8J8BWiYB6oAm7PK3yERbKvNQp0Q2+zaPRtyKR825CXNndCFCgWqp0z3nAHFeF7hI=@vger.kernel.org X-Gm-Message-State: AOJu0YyeXdnvSdCMLmoudenp6YWz+xzEhugY2bGBII8+F//efc94z19c KHXC3Fh4GUY8pIOKos66otEnKKj1P+kPF/i6yN+4TNgzpJxFwlqU+oKJ1XLh56e8RCKkDthZzJS aXiwR4g== X-Received: from pgda17.prod.google.com ([2002:a63:7f11:0:b0:c6e:28c3:dd61]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:a395:b0:34a:4b04:3c70 with SMTP id adf61e73a8af0-39517e11fdamr13193721637.25.1771878241255; Mon, 23 Feb 2026 12:24:01 -0800 (PST) Date: Mon, 23 Feb 2026 12:23:59 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: 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 Mon, Feb 23, 2026, Yosry Ahmed wrote: > > > > > > 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... > > Kinda? What I am getting at is that we'll always have an old KVM that > doesn't save everything that we'll need to handle. I think the > scenario you have in mind is where we introduce a feature *after* we > start saving everything, and at a later point realize we didn't add > proper "restore" support, but the "save" support must have always been > there. Yes. > gPAT is not a good example because it's in the "save" area :P Oh, I don't think I realized this is only talking about the control area. Or I probably forgot. > But yeah, I see your point. It's not very straightforward now because > what we save comes from the cache, and we only cache what we need for > the current set of features. So this will need to be done on top of > the rework we've been discussing, where vmcb02 starts being the source > of truth instead of the cache, then we just (mostly) save vmcb02's > control area as-is. Yeah, it's not urgent by any means.