From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 E47AF1E22E9 for ; Wed, 11 Feb 2026 00:39:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770770372; cv=none; b=c+2xjdnWTCz1fQQQVgOZgTE/fpht6mIXIl7U7rnoaBvoUf+KPFdKv24x3NWpG9h7M6XGEXPEkL+qiJeLAKobwCWkX3KvrUeFWG5GYc6arQKY6Oq28NHT6+EttwmcuA74/hrSU9TSmS/J5PdosQANQP3vKe1s5zPf/mzuZe0pumc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770770372; c=relaxed/simple; bh=s2U9S1u3VhkDUIygI3Zcx38PmHTM+Bthud/9UyO7iso=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=aj/G2Xiu7qfvjFyNeh4QrAOH/txp924hqiYefacKrU5gXB7b1KY4/RqEgcVaIGaBjPKz/fN+xwWAsJK74FGYGu1mSMNm9ooJ3fLEK/HTs+tqPA3xtPvsDgC4RJNHLjD1iOERmIdHwu/orGK4McYl9rEHdEn1DnDVa/prCSx17h0= 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=RJJ9kxfX; arc=none smtp.client-ip=209.85.214.201 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="RJJ9kxfX" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2a377e15716so117866665ad.3 for ; Tue, 10 Feb 2026 16:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770770370; x=1771375170; 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=jlPZqqOFKtlyTJtQPaMC04tH30yMSKXkqW8o2Hw3yFU=; b=RJJ9kxfXO9fkA5U61fR+/vx5DUlcQ7q5xty7uFUJvLoHKl+nYJCHUw7F0djAVLLoiQ MIFVUrrWSiU30zAPKgdoVvfjc5y9IPMPIxnPnWhTagRmIBTzPFmWFcwEmTeGs3Nis/KH dQ9wIy2Ul4HY/n+bAX8ujsMXcVK5SIS3iC8LZVuwClydOFqTG4sSLyS0sqvJ5UeUlf2+ z+nrO8IJ7HiFFDQsYw5AnN/3qEkH2r7MFaz1tVblXFAL+UmWcO2akrhYXd4INTy1Fpyh FmXB4tDBDSCHMpKT8tuup8KbbqAV97qLURKG2sffuCvGRG9HdmPM+Mra5gilYpmOk1o2 SuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770770370; x=1771375170; 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=jlPZqqOFKtlyTJtQPaMC04tH30yMSKXkqW8o2Hw3yFU=; b=c+yUQgKY2dfkOuHG+4zRRrrxjGWxyvztpOtmcjRe0aH0zLSMlkkktY0eHV65EEzDY+ SBW1GCy7P+sITVjyQjKl2ZBAOd1/IrakMDszHCrOArueoPqtk8tN1yoagoc4ZsQda7eR dAZ5lKc/jJ1LQo3SMpEAKjaeya5G5lAIL3goBqi+FCIeXTJsraWtzKuwgJbzBUoYnqYd 48A/LxTMuUhrzpDZD6sRXI9hS+QTNSWOByDBedgCCOGnnPEIt9CzoPY+IL4qrGCE/d8V KH+GeymvNcphti+CNlNA3yD4eLVddkU1yjAfSXwAsBFBF2HcU8zh5BAlKyoTIPxGOiwx F4Wg== X-Forwarded-Encrypted: i=1; AJvYcCUg6rbXDQgnO3nIGZLo7cMnKtsamj+Y8f8bcdy/yMI5rrwXqpPY9vsoNNcB9NiMTKDEYT/sj5k=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6WkAI3992RXOhOHNZrLXMYxGLbaquhALEptCUnED4L7s+0dsm 0jD8lS9OYw9XmvB/n4QhbTUqqe4cR06E8l3BfeX8NLUodDQDS47OOMUPUOODOK6uDRgNEtUmr+5 NIUVDiA== X-Received: from plgo9.prod.google.com ([2002:a17:902:d4c9:b0:2a9:5e11:35e3]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:238b:b0:2aa:e7f3:fb05 with SMTP id d9443c01a7336-2ab280e2dc9mr9332135ad.59.1770770370341; Tue, 10 Feb 2026 16:39:30 -0800 (PST) Date: Tue, 10 Feb 2026 16:39:28 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260210005449.3125133-1-yosry.ahmed@linux.dev> <20260210005449.3125133-2-yosry.ahmed@linux.dev> <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: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Wed, Feb 11, 2026, Yosry Ahmed wrote: > > > We can drop it and make it a local vaiable in nested_svm_vmrun(), and > > > plumb it all the way down. But it could be too big for the stack. > > > > It's 48 bytes, there's no way that's too big. > > That's before my hardening series shoved everything in there. It's now > 256 bytes, which is not huge, but makes me nervous. Especially that it > may grow more in the future. > > > > Allocating it every time isn't nice either. > > > > > Do you mean to also make it opaque? > > > > I'd prefer to drop it. > > Me too, but I am nervous about putting it on the stack. 256 bytes should be tolerable. 500+ is where things tend to get dicey. > > > > + u8 __vmcb12_ctrl[sizeof(struct vmcb_ctrl_area_cached)]; > > > > > > We have a lot of accesses to svm->nested.ctl, so we'll need a lot of > > > clutter to cast the field in all of these places. > > > > > > Maybe we add a read-only accessor that returns a pointer to a constant > > > struct? > > > > That's what I said :-D > > > > * All reads are routed through accessors to make it all but impossible > > * for KVM to clobber its snapshot of vmcb12. > > > > There might be a lot of helpers, but I bet it's less than nVMX has for vmcs12. > > Oh I meant instead of having a lot of helpers, have a single helper that > returns it as a pointer to const struct vmcb_ctrl_area_cached? Then all > current users just switch to the helper instead of directly using > svm->nested.ctl. > > We can even name it sth more intuitive like svm_cached_vmcb12_control(). That makes it to easy to do something like: u32 *int_ctl = svm_cached_vmcb12_control(xxx). *int_ctl |= xxx; Which is what I want to defend against. > > > I think this will be annoying when new fields are added, like > > > insn_bytes. Perhaps at some point we move to just serializing the entire > > > combined vmcb02/vmcb12 control area and add a flag for that. > > > > If we do it now, can we avoid the flag? > > I don't think so. Fields like insn_bytes are not currently serialized at > all. The moment we need them, we'll probably need to add a flag, at > which point serializing everything under the flag would probably be the > sane thing to do. > > That being said, I don't really know how a KVM that uses insn_bytes > should handle restoring from an older KVM that doesn't serialize it :/ > > Problem for the future, I guess :) 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.