From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.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 19AF12F9C3D for ; Fri, 6 Feb 2026 23:07:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770419223; cv=none; b=jl2L8mJZTeY6lGfjNVDffle0iIPwVCTmdEpT/jMZA2dMqXx3T4+FFctMqo93fl+FBAyION67dp8wlmNJq/fEb/ccI8fkoJlmSuEqlj28kmYTe1sn2EDWcxs7pGQK8YmTL75+V1r8FTV3NeGeRVAq98vkCdL6j0I98w0dYDTUOmI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770419223; c=relaxed/simple; bh=FcYDzvYt6qRCfMBuYQg/fNZI/Ov7o7ltbY9lGgUO2kM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=tV2+oy+dztuXdUfkUN2Y9a+eCLSc8j+rxOG9l69eAKPcbsi0DrfYTNqnaMue2oB4IGYb7GehQqxPEHiWtscWltJPbw/wA81L6EMOJGGlATpFhqSehjP34AP88hzV5g9FvVOcU3gV/v/ilttXFme2IseErCPprkC/WED9DXNc1u0= 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=IKsXX8G9; arc=none smtp.client-ip=209.85.210.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="IKsXX8G9" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-82442b44d94so711349b3a.2 for ; Fri, 06 Feb 2026 15:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770419222; x=1771024022; 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=KZYAv7PTE+yvvy/ZSJd8rfyOzgaRiZuGA2UK+o3e2Dc=; b=IKsXX8G93tbTYFPP3ASBcU66NWVIpzE/0Cgtvu7rXa+gc80NfMLcyCV/RD8VcvYdxl ouY4zvKjE5h1x2T55o/nU2dDw+KCgMS/RJKVjIlDUJ7dRZjOS23MIq5THawr5GhYtdny DV7NqzLAvypH0eRFhuMoD/aLZ1e9xxq1j2+kDBoO5IyoyEQyzWwa2hZgM/2MPpi2RIx5 8N2cngOFJansRlSfWNEcfxuDLGSMiWWkS21jr6VORg0bb0gLR1ZQ8zrVEqgoM52fH+la zkfP3Jqwbx1vn1LexD8pvLCTveQwNjA5jh3OYu//psTam2q1SrREtoN9Z/vR+DJJBxPT oaBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770419222; x=1771024022; 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=KZYAv7PTE+yvvy/ZSJd8rfyOzgaRiZuGA2UK+o3e2Dc=; b=G4lZjPItySZUIh/q3de3GdDBoqDEwcIG5Oyz5+odhqMCaNCfA1le0P46dx0u9YS/X7 Ze/6TM/B4mfCvpIYYwzZE+lpzC62HgIe7K6IjHA49J1uvFtfVAfq2zkgGmEryVlfnCk7 zVxkjjnNeyJfMq1pM3yH2aoqbaGWjSUio9BlN2i2G5oG9fU6Dnj/DpyGE++nzc37fiUB glu8CkUVQ/H/hq0MFc5NLEh3qGHpSWCkkMlngzCeZa41WwyfjaPQAR7TmBoI9yAD84Lh yuf5WBSUxBUtgOMxmfLD63d1gigWw9ej4OzaTqkijGvE4LyYO4kxjvqa85jZD2LIigCr 5ZeQ== X-Forwarded-Encrypted: i=1; AJvYcCXvs2JEFDxSfNTbuzdqGhAG55+60pK1P/4aaAnAhReeccUatnZB4SiaWipQIpqZCg01VPkwQfiZhqcdyCM=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+V3wIwsNiWI9xVXG1VnRCgw7IxUqXn2L8N0/5pjDWXbMWjKIB zoWunmZvIUn6Vc+CqImJghHD5S32l3Lz4qEjGjAiFAKOF2XNmBxuWPlTo0aBD1wndUMR1aqe9tC B0F8+Kw== X-Received: from pfbkq17.prod.google.com ([2002:a05:6a00:4b11:b0:823:6d9:cee8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:e0a:b0:81f:852b:a934 with SMTP id d2e1a72fcca58-82441623946mr3395482b3a.24.1770419222227; Fri, 06 Feb 2026 15:07:02 -0800 (PST) Date: Fri, 6 Feb 2026 15:07:00 -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: <20260205214326.1029278-1-jmattson@google.com> <20260205214326.1029278-3-jmattson@google.com> Message-ID: Subject: Re: [PATCH v3 2/8] KVM: x86: nSVM: Cache and validate vmcb12 g_pat From: Sean Christopherson To: Jim Mattson Cc: Yosry Ahmed , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Shuah Khan , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 06, 2026, Jim Mattson wrote: > On Fri, Feb 6, 2026 at 11:12=E2=80=AFAM Sean Christopherson wrote: > > > > On Fri, Feb 06, 2026, Jim Mattson wrote: > > > On Fri, Feb 6, 2026 at 10:23=E2=80=AFAM Yosry Ahmed wrote: > > > > > > > > February 6, 2026 at 10:19 AM, "Sean Christopherson" wrote: > > AFAICT, the only "problem" is that g_pat in the serialization payload w= ill be > > garbage when restoring state from an older KVM. But that's totally fin= e, precisely > > because L1's PAT isn't restored from vmcb01 on nested #VMEXIT, it's alw= ays resident > > in vcpu->arch.pat. So can't we just do this to avoid a spurious -EINVA= L? > > > > /* > > * Validate host state saved from before VMRUN (see > > * nested_svm_check_permissions). > > */ > > __nested_copy_vmcb_save_to_cache(&save_cached, save); > > > > /* > > * Stuff gPAT in L1's save state, as older KVM may not have sav= ed L1's > > * gPAT. L1's PAT, i.e. hPAT for the vCPU, is *always* tracked= in > > * vcpu->arch.pat, i.e. gPAT is a reflection of vcpu->arch.pat,= not the > > * other way around. > > */ > > save_cached.g_pat =3D vcpu->arch.pat; >=20 > Your comment is a bit optimistic. Qemu, for instance, hasn't restored > MSRs yet, so vcpu->arch.pat will actually be the current vCPU's PAT > (in the case of snapshot restore, some future PAT). Yeah, FWIW, I was _trying_ account for that by not explicitly saying that a= rch.pat is the "new" L1 state, but it's difficult to dance around :-/ > But, in any case, it should be a valid PAT. > > > if (!(save->cr0 & X86_CR0_PG) || > > !(save->cr0 & X86_CR0_PE) || > > (save->rflags & X86_EFLAGS_VM) || > > !nested_vmcb_check_save(vcpu, &ctl_cached, &save_cached)) >=20 > Wrong ctl_cached. Those are the vmcb02 controls, but we are checking > the vmcb01 save state. *sigh* > I think it would be better to add a boolean argument, "check_gpat," > which will be false at this call site and nested_npt_enabled(vcpu) at > the other call site. Yeah, agreed. Because even though arch.pat should be valid, IIUC there isn= 't a consistent check on hPAT because it's never reloaded.