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 5A76E2C0F90 for ; Fri, 13 Feb 2026 22:19:05 +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=1771021146; cv=none; b=odGvyXw8fi9rfOUaoZMw4DabwoUM+eck5ZLr3MR9BAP7+C4o9ESrYhpqJ0zyx7fjskFeCoHAtI4GkkEPCoqCDfBARPL/eviGvFKJNZEtoWxNw71YBixJFydJl7Sw3fZtS9lOe9UvhP9aVwTkNk+MDXpaTJxIFmr79Ob+JVOKiCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771021146; c=relaxed/simple; bh=4SfVeVyOopNUEYpALsPtH/J4tdgq8bQHBnqCt9tGo8k=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=l2HJonhdZpJh7Bp6YOhp20RTA3nISyNsti/YHbsvHmCGQgfCFj6QqKO3rcy9UEqWR5UeAIALTaZsUKpCXlYE8ZGtQvCHIZ6Yrmb0vIsd9GXlxMGBG9XgQ+24exFSE6PuQPDzVnLAhEdfVzFWDGVrL3fAM3WX2T9qAmo3+cUqDV0= 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=lp1JxfpW; 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="lp1JxfpW" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ad147cdf07so4364515ad.2 for ; Fri, 13 Feb 2026 14:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771021145; x=1771625945; 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=zjKURXqU+Zr0HcMfUxCtx2SVToxbcyc0zFBF1VQb9Ag=; b=lp1JxfpWhfKo64z3xcrr73d7ItxzQ3cbS4g+iRbelY9/K5W/lqlEuLHKzRPoh1kwXC m68lShZZqkRFoNhqg0eODPykfNVZhSZaRUac+U22U74avuLy9LwNpiLDMR5gkdfKeXuo qBs0Eo1M7+7WNKiZbvCp9CTeBopKn7T9x+VYBMG8h79nuUoLZlKJk/zNR+3A7Ndfp7Ah R5OzxMVpjhyUxozDLYOLJsEBoyeXzoa3dvP/SLKD2Ne9XdVjY/sWRPzPjiktI4f/Incn 1reJvTBad01CcKJeUMhfobFEiIA2YSz+FGj0mud9ZfDJHC11tTF9wXPriWPsZmQd+qiC ez2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771021145; x=1771625945; 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=zjKURXqU+Zr0HcMfUxCtx2SVToxbcyc0zFBF1VQb9Ag=; b=t07m5RtdZ3TAGQcA+SWCAVWH6Bmy9lF9tfqTwcegzt18tGXocAVaDCTwXYjVCigZbW Uip6g4RgggnYJC11tP1jJTCyIkTpA3JWhpyydLdT+SbXYkXvhkOqSpN2jBS/BWsNmtp1 1cPXA+lY8Zc+GMbWCn1t5fLaCUER1od0c2g0jN3rtMPaBzNbzVcarvrT9YCSs2txkGc9 z3vlhGhE0O++iucfGRSaKD78iADWz0Lnt1D6tnRlXZYvvI5eOfmJF64+oQ3n81Up/PiB KaaoXGDmMnkelkpAsyu2TDMHpL2PSmdyn1819huIE/fl6qPxum9cNbl2NAcZhDIzXc40 sHGg== X-Forwarded-Encrypted: i=1; AJvYcCU+wmFt+HTzz6qdYp3l6pc2wUNm0baSwuFM7gGy8Ud9/mWwy2RZywxGgvaQs293jUqVSuEakbwUGN42anA=@vger.kernel.org X-Gm-Message-State: AOJu0YybPbOrsOq7+E+hxrqbcNQDznvV84mC93zM/b0z9xDr0j/0jNL4 xX52EjjGxVIoLEDm38GPHCHB54Tq6GQeG7XixY9I2T+H4BWVGXwD+d9D0diNX/2LP58HfHLWS2T m5sANxw== X-Received: from pjbsx13.prod.google.com ([2002:a17:90b:2ccd:b0:354:c63c:5ed6]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:1c2:b0:2a7:9ded:9b4a with SMTP id d9443c01a7336-2ad174dcf04mr9334615ad.36.1771021144404; Fri, 13 Feb 2026 14:19:04 -0800 (PST) Date: Fri, 13 Feb 2026 14:19:02 -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: <20260212155905.3448571-1-jmattson@google.com> <20260212155905.3448571-5-jmattson@google.com> Message-ID: Subject: Re: [PATCH v4 4/8] KVM: x86: nSVM: Redirect IA32_PAT accesses to either hPAT or gPAT 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 13, 2026, Jim Mattson wrote: > On Fri, Feb 13, 2026 at 7:20=E2=80=AFAM Sean Christopherson wrote: > > > > +static inline void svm_set_hpat(struct vcpu_svm *svm, u64 data) > > > > +{ > > > > + svm->vcpu.arch.pat =3D data; > > > > + if (npt_enabled) { > > > > Peeking at the future patches, if we make this: > > > > if (!npt_enabled) > > return; > > > > then we can end up with this: > > > > if (npt_enabled) > > return; > > > > vmcb_set_gpat(svm->vmcb01.ptr, data); > > if (is_guest_mode(&svm->vcpu) && !nested_npt_enabled(svm)) > > vmcb_set_gpat(svm->nested.vmcb02.ptr, data); > > > > if (svm->nested.legacy_gpat_semantics) > > svm_set_l2_pat(svm, data); > > > > Because legacy_gpat_semantics can only be true if npt_enabled is true. = Without > > that guard, KVM _looks_ buggy because it's setting gpat in the VMCB eve= n when > > it shouldn't exist. > > > > Actually, calling svm_set_l2_pat() when !is_guest_mode() is wrong too, = no? E.g. > > shouldn't we end up with this? >=20 > Sigh. legacy_gpat_semantics is supposed to be set only when > is_guest_mode() and nested_npt_enabled(). I forgot about back-to-back > invocations of KVM_SET_NESTED_STATE. Are there other ways of leaving > guest mode or disabling nested NPT before the next KVM_RUN? KVM_SET_VCPU_EVENTS will do it if userspace forces a change in SMM state: if (!!(vcpu->arch.hflags & HF_SMM_MASK) !=3D events->smi.smm) { kvm_leave_nested(vcpu); kvm_smm_changed(vcpu, events->smi.smm); } I honestly wasn't even thinking of anything in particular, it just looked w= eird. > > > > + vmcb_set_gpat(svm->vmcb01.ptr, data); > > > > + if (is_guest_mode(&svm->vcpu) && !nested_npt_enabled(sv= m)) > > > > + vmcb_set_gpat(svm->nested.vmcb02.ptr, data); > > > > + } > > > > +} > > > > > > Is it me, or is it a bit confusing that svm_set_gpat() sets L2's gPAT > > > not L1's, and svm_set_hpat() calls vmcb_set_gpat()? > > > > It's not just you. I don't find it confusing per se, more that it's re= ally > > subtle. > > > > > "gpat" means different things in the context of the VMCB or otherwise= , > > > which kinda makes sense but is also not super clear. Maybe > > > svm_set_l1_gpat() and svm_set_l2_gpat() is more clear? > > > > I think just svm_set_l1_pat() and svm_set_l2_pat(), because gpat straig= ht up > > doesn't exist when NPT is disabled/unsupported. >=20 > My intention was that "gpat" and "hpat" were from the perspective of the = vCPU. >=20 > I dislike svm_set_l1_pat() and svm_set_l2_pat(). As you point out > above, there is no independent L2 PAT when nested NPT is disabled. I > think that's less obvious than the fact that there is no gPAT from the > vCPU's perspective. My preference is to follow the APM terminology > when possible. Making up our own terms just leads to confusion. How about svm_set_pat() and svm_get_gpat()? Because hPAT doesn't exist whe= n NPT is unsupported/disabled, but KVM still needs to set the vCPU's emulated PAT= value.