From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.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 7875833A9FF for ; Tue, 24 Feb 2026 20:42:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771965780; cv=none; b=YLeX+YTVCDu8lpwSjmlwqEC/XDR+56H/NfhGF+Uu1tCPfaXWhvXREuxe44MLrzqZ5629aluGl2OC6P5+MIFvrD8nPLLtqINRf8ppvCioBV2g/p59/3rP8nrs2Wvnmf0aEhuerAWnHINOHInBmDP62sFkvb5dzbDi5yJHE8FbGp0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771965780; c=relaxed/simple; bh=FFSIws9UZGCXCXlSxRzmXwLBnorm0MrWfAEBYQi/VmE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ojlzb7sI5UaOSRsmY3h6sb0qAH30T1aYgnfE4wyJWYUlTWi4ZLG2rpV8k/0S1IRdGpSV1ReObTIfDxPdaDoGLH2Lo3IYdrIoIk9CjAQJ31xkMzcnZyXvhMSEDbP0DigQ6IV54BdJCDuDISlvFz5wxnkUEZTid7hJ0Q8w0lq3PJU= 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=TE+Tekd7; arc=none smtp.client-ip=209.85.215.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="TE+Tekd7" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c61dee98720so3468686a12.0 for ; Tue, 24 Feb 2026 12:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771965779; x=1772570579; 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=HQvkurqnzRl0s4Cu5TERD53tESfJg6za9bkF8vg/CkM=; b=TE+Tekd7Wz7ojRzrcmmlV5AsSft7za7NWXFnkZj7xOJzugQ9Z1C0P5c9RZfeSRtPC5 7dsZls594EkfmT6lYh2GT2uXwvWq0fRpFdLPudSeImbWVeTjSRsUM/m7felW4efxNZoU ZWpERE+O0HUsVF8bH2GibyFRAwKYOISoqWAkEMaVdKChk2akbuBPLOWtE9Q4bNhr247X 9opT/Bv+rEDxy5ZwFUghPJCwNz6nzq4hscnN4fWFYPIK41acDf2jgYCyaq0qztnLRybN ZRitTEKJfb+MRwzMnEEkRz8i/WQgTlRLRn1lyt5n9/2/92oxNUsBd4AaF0I2tVGppXAI 2VSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771965779; x=1772570579; 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=HQvkurqnzRl0s4Cu5TERD53tESfJg6za9bkF8vg/CkM=; b=UhGe1aMB6dsp/WHLFBb8aUBsUvbGPI6sEPW/SdLJlVlkkNXW96RhFbUc7fJZkmwYkJ 2ssSeusc05eXvLO/fhIKX5Jk6UfigtYSCM6QU5wjt6iDLPnox/Fv9PZ6XtPE6phjxKgL fLAfWNTjfGuwLlzCLs1Rf0yOOb1w9CFrFOUOOAJuRXtPnZ4btda0Nsdk0k6hInS3OLbr pS3YIKPcPhFEiCn/6Nz2mUc+Ug2DadSDWa+TxzaAaPEWWUuBgD0BgMszUjG07kCVNF2E IoVWIqLV7qCqakIvGLC352r5Zq2sokvDkGZPFaL3YittiGSTR2VcluroLPs4JtyqYYsB /9FA== X-Forwarded-Encrypted: i=1; AJvYcCXXYJUisA5HYkPS5/Zn4jCrK4fHhtAEbLA5XyU1Ir/g/sq0Q4CIf+uLp18aZnZebZsDMkGyqc5wvlwAWU0=@vger.kernel.org X-Gm-Message-State: AOJu0YyMwAMfN0EV9GIXjupbcZml/ebbU0lQEyyppAxANl/eVIJRKI4Z +A85NH3Mlm6AwA1ZdpAz9VTWx4V7XMu4JMb9Kw+1BL3Y8KuKkbfmHgtoR/3RPkbna6CCK4lQ8Kc xa9/49Q== X-Received: from pgeh26.prod.google.com ([2002:a05:6a02:53da:b0:c6e:1954:345]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:3c89:b0:364:be7:6fe9 with SMTP id adf61e73a8af0-3959f2f33b9mr96391637.32.1771965778642; Tue, 24 Feb 2026 12:42:58 -0800 (PST) Date: Tue, 24 Feb 2026 12:42:57 -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: <20260223214336.722463-1-changyuanl@google.com> <213d614fe73e183a230c8f4e0c8fa1cc3d45df39.camel@intel.com> Message-ID: Subject: Re: [PATCH] KVM: TDX: Set SIGNIFCANT_INDEX flag for supported CPUIDs From: Sean Christopherson To: Rick P Edgecombe Cc: "binbin.wu@linux.intel.com" , "kvm@vger.kernel.org" , "changyuanl@google.com" , Binbin Wu , "x86@kernel.org" , "kas@kernel.org" , Xiaoyao Li , "hpa@zytor.com" , "mingo@redhat.com" , "bp@alien8.de" , "pbonzini@redhat.com" , "tglx@kernel.org" , Isaku Yamahata , "linux-kernel@vger.kernel.org" , "linux-coco@lists.linux.dev" , "dave.hansen@linux.intel.com" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2026, Rick P Edgecombe wrote: > On Tue, 2026-02-24 at 08:03 -0800, Sean Christopherson wrote: > > > But adding the consistency check here would cause compatibility issue= . > > > Generally, if a new CPUID indexed function is added for some new CPU = and > > > the TDX module reports it, KVM versions without the CPUID function in > > > the list will trigger the warning. > >=20 > > IMO, that's a good thing and working as intended.=C2=A0 WARNs aren't in= herently > > evil. While the goal is to be WARN-free, in this case triggering the WA= RN if > > the TDX Module is updated (or new silicon arrives) is desirable, becaus= e it > > alerts us to that new behavior, so that we can go update KVM. > >=20 > > But we should "fix" 0x23 and 0x24 before landing this patch. >=20 > Would we backport those changes then? I would usually think that if the T= DX > module updates in such a way that triggers a warning in the kernel then i= t's a > TDX module bug. To stable@? No, I don't think see any reason to do that. > I'm still not clear on the impact of this one, but assuming it's not too > serious, could we discuss the WIP CPUID bit TDX arch stuff in PUCK before= doing > the change? Sure, I don't see a rush on the patch. > We were initially focusing on the problem of CPUID bits that affect host = state, > but then recently were discussing how many other categories of potential > problems we should worry about at this point. So it would be good to unde= rstand > the impact here. >=20 > If this warn is a trend towards doubling back on the initial decision to = expose > the CPUID interface to userspace, Maybe I'm missing something, but I think you're reading into the WARN waaaa= y too much. I suggested it purely as a paranoid guard against the TDX Module doi= ng something bizarre and/or the kernel fat-fingering a CPUID function. I.e. t= here's no ulterior motive here, unless maybe Changyuan is planning world dominatio= n or something. :-D > which I think is still doable and worth considering as an alternative, th= en > this also affects how we would want the TDX module changes to work.