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 03FC33806B7 for ; Tue, 24 Feb 2026 16:03:18 +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=1771949001; cv=none; b=DvK8+89419jUvdoPLP63/JCdYsZQbkCPcz77KH6MtWiYiXpQJzyqGzMPWPdXq+WgiekBJWD/RgCWr1+HapuCqxl/D9UwojT7eb5mH9QcEIl9qaQllmzKSINKifntXC5G9EecO+jgc7TV1k+XvPbTENS53HIn0DQRQUMXf7Bw+YE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771949001; c=relaxed/simple; bh=SOGQy7+puNM/ba13/nSnregfmqZzlkrJ68UTA3YXxRU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=m/tJ0+t8FJTDpM7ya3iJrcphG2jE6yIptO1mtFTppLBJennmH3z6QNxo2rDwiPbMkgQ4YYCBG649XdE6ObqmpbKz+Tq0rgijX4mepoEe7WVMUtnBcuwyBIoXXc+k/BysR++L5BpjYdOfdbDeTs6aW4r4stxJ6NhdS3MRWosFkMk= 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=eruSefUa; 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="eruSefUa" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c6e1d074b26so3413973a12.3 for ; Tue, 24 Feb 2026 08:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771948998; x=1772553798; 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=p31fbkWSCceudE7NtBIgU6iz/jD9HBtJctESA+fNTjk=; b=eruSefUaFLQaZBlJ5Hp8FGggSqqYOKEYMkK6Wee3IBJ9wkivduEWRVb683N2aeQtTf yz8PfcgurQVvbDdgGBiptQ46f5LpV3g5Ug1BLlzcUR1JE+2rJ4uRMJ2Aqdly7L9oa9L/ sTzXSww2T0r8ozqyQxMhWr14Gc8tUe2S0nJyitjyVvK7W9heoaKntD9snaMBzOI4CjR5 /8qTBFM6nkfKyPKcipN77GLR2AjWmWNH/zh0sTqareBgldM8v819bKGvgPC2riyxPE6y RrdMMl4EwWZX4jvnAjoIQxk3gk2rLxK5yra6H7WXoF+ctmSBb8l3q9LwcxCNdds9hZXh yo4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771948998; x=1772553798; 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=p31fbkWSCceudE7NtBIgU6iz/jD9HBtJctESA+fNTjk=; b=jZypbk0USo5IQHL1uZwIQU/tFDuYuUnoNbY6/ut7sx3wND3psuvmHGHNOGDiZ3xs03 VFMRmc172AbgngCBIZA+irgXeto+8Kr4znxmMbGrVvAkYKR4tmNojZpQyd/CyAKQ9qOV 6SK9AEDj72hXEUgllNctqeBeKYnwdjqe2yPAQ1qx6lPXsAkMESjIagQyTQynEWZkS3xB pB8rGI22ajXwkp+sI4RAo0psylKThfb8FAf7RBS52v5kWpfXvrghLGa+SjKKvnS+3xnZ +IpnUYiArxWfWTpEfbQHp2RylR//LqSwlNwp+VmDznmY+XZjwv6UUvIIkneZOn2lEwgg /7Ig== X-Forwarded-Encrypted: i=1; AJvYcCXJsQDI3i9Cpc/wxfZ8ZZT9n0GAb40ALYmw85/cQag/EQyRRAvjHzDVSxP3XPwJsKQNq66M8/SQMMFD9P0=@vger.kernel.org X-Gm-Message-State: AOJu0YwlkA4NxkddJIR/JvtpMZaTth2ueAqkECVS1brPNfA4pptpkDYb LfkxSQajftqz8NerAwH2QBj01Eo/+8t1YXHYa7kUI1bQ/+PeK7f3dVyK8Yr9PM3IO5tbBJK/nAd WWKUBVw== X-Received: from pgcv16.prod.google.com ([2002:a05:6a02:5310:b0:c16:a39f:5b40]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:898b:b0:394:a026:4c74 with SMTP id adf61e73a8af0-39545f7d1f2mr10096820637.40.1771948998111; Tue, 24 Feb 2026 08:03:18 -0800 (PST) Date: Tue, 24 Feb 2026 08:03:16 -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: Binbin Wu Cc: Rick P Edgecombe , Xiaoyao Li , "changyuanl@google.com" , "pbonzini@redhat.com" , Binbin Wu , Isaku Yamahata , "bp@alien8.de" , "x86@kernel.org" , "kas@kernel.org" , "hpa@zytor.com" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "dave.hansen@linux.intel.com" , "tglx@kernel.org" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2026, Binbin Wu wrote: > On 2/24/2026 9:57 AM, Edgecombe, Rick P wrote: > >> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c > >> index 2d7a4d52ccfb4..0c524f9a94a6c 100644 > >> --- a/arch/x86/kvm/vmx/tdx.c > >> +++ b/arch/x86/kvm/vmx/tdx.c > >> @@ -172,9 +172,15 @@ static void td_init_cpuid_entry2(struct > >> kvm_cpuid_entry2 *entry, unsigned char i > >> =C2=A0 entry->ecx =3D (u32)td_conf->cpuid_config_values[idx][1]; > >> =C2=A0 entry->edx =3D td_conf->cpuid_config_values[idx][1] >> 32; > >> =C2=A0 > >> - if (entry->index =3D=3D KVM_TDX_CPUID_NO_SUBLEAF) > >> + if (entry->index =3D=3D KVM_TDX_CPUID_NO_SUBLEAF) { > >> =C2=A0 entry->index =3D 0; > >> + entry->flags &=3D ~KVM_CPUID_FLAG_SIGNIFCANT_INDEX; > >=20 > > There are two callers of this. One is already zeroed, and the other has > > stack garbage in flags. But that second caller doesn't look at the > > flags so it is harmless. Maybe it would be simpler and clearer to just > > zero init the entry struct in that caller. Then you don't need to clear > > it here. Or alternatively set flags to zero above, and then add > > KVM_CPUID_FLAG_SIGNIFCANT_INDEX if needed. Rather than manipulating a > > single bit in a field of garbage, which seems weird. +1, td_init_cpuid_entry2() should initialize flags to '0' and then set KVM_CPUID_FLAG_SIGNIFCANT_INDEX as appropriate. > >> + } else { > >> + entry->flags |=3D KVM_CPUID_FLAG_SIGNIFCANT_INDEX; > >> + } > >> =C2=A0 > >> + WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=3D > >> + =C2=A0=C2=A0=C2=A0=C2=A0 !!(entry->flags & > >> KVM_CPUID_FLAG_SIGNIFCANT_INDEX)); > >=20 > > It warns on leaf 0x23 for me.=C2=A0Is it intentional? >=20 > I guess because the list in cpuid_function_is_indexed() is hard-coded > and 0x23 is not added into the list yet. Yeah, I was anticipating that we'd run afoul of leaves that aren't known to the kernel. FWIW, it looks like 0x24 is also indexed. > It's fine for existing KVM code because cpuid_function_is_indexed() is > only used to check that if a CPUID entry is queried without index, it > shouldn't be included in the indexed list. >=20 > 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. IMO, that's a good thing and working as intended. WARNs aren't inherently = evil. While the goal is to be WARN-free, in this case triggering the WARN if the = TDX Module is updated (or new silicon arrives) is desirable, because it alerts = us to that new behavior, so that we can go update KVM. But we should "fix" 0x23 and 0x24 before landing this patch.