From nobody Sun Dec 14 11:14:56 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E3332FF161; Mon, 3 Nov 2025 23:44:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762213479; cv=none; b=orN+NngmDVwG9+bbEeXSY1VWnWiXn8oi4e1ih3sqEUpfd2dc9CuiifBfqeGbLbUFOLQxo77P1f3ufvNuUgPisplQ9yTAMiDapbd3K8uKY278BB0vhz7onqH6ecGlIVVZjuZaonkrgQzbyOU/nqtg5+iNBvwgvBWxq9xF0WAytuk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762213479; c=relaxed/simple; bh=1CX/p1kddQMlKdnXAU8Vqn2zt154h9mj7ISIqvBDh48=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=m6rx9DYGRGEqaFSwSG6ngOV9HBeb0SJ8q0QPxHLcHGSyjwZzQ5dAo4utYJl8h6Ru8OyhTWUrAl4uBcV2bCj+mooWuDkKLoAT5IoEsftMFwuT3wMY/YQyKPNzh5CHXLLuTIz8tSocauXSFjgNMZm00/Z/qZKm5T0Rbf3MteP/eRw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=RBo3uqyV; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="RBo3uqyV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1762213478; x=1793749478; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=1CX/p1kddQMlKdnXAU8Vqn2zt154h9mj7ISIqvBDh48=; b=RBo3uqyVl/5gemRG+XkGyp9IJVlkB3M1rkWvr7018SK2nURiSE+HgF1R 6IpNrqNbs6j6FZg/Bgy8kH1AnhsemnCpIFWc7lDEcIWgPrtMowGQLzkli ZFxeBdhN5zWWsi6n12YTdYlT+MT8c8TmANE6YYGrd467JzqrpfbHa7aE1 WzzRdUk6K2lk+MU9zqYYDjmBhwK2fdEm9maTAgJ325FLFnAA+nj6GxZlX buvPj6jFI+nBtpsASchLYnej1wiGYyjgWTZwIFVVzttdjsOqZq+NTFQ/n FwvLzuxR1G8MrODgegQkZMU435h4syeZXMWySkrSX7gwnM4tIV8wCd8y8 w==; X-CSE-ConnectionGUID: A5W6SPXNQ/in6qfyVLXUPg== X-CSE-MsgGUID: eeyUlv/lRGyhOJa8zuY/iA== X-IronPort-AV: E=McAfee;i="6800,10657,11602"; a="64217936" X-IronPort-AV: E=Sophos;i="6.19,277,1754982000"; d="scan'208";a="64217936" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2025 15:44:37 -0800 X-CSE-ConnectionGUID: My+YqEBUS+CU6fznRMDJQA== X-CSE-MsgGUID: U6phfDb7TdGjyq+Y+Q5C9A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,277,1754982000"; d="scan'208";a="187150888" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 03 Nov 2025 15:44:37 -0800 Subject: [v2][PATCH 1/2] x86/virt/tdx: Remove __user annotation from kernel pointer To: linux-kernel@vger.kernel.org Cc: Dave Hansen , Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , kvm@vger.kernel.org, Paolo Bonzini , Rick Edgecombe , Sean Christopherson , Thomas Gleixner , x86@kernel.org, Xiaoyao Li From: Dave Hansen Date: Mon, 03 Nov 2025 15:44:37 -0800 References: <20251103234435.0850400B@davehans-spike.ostc.intel.com> In-Reply-To: <20251103234435.0850400B@davehans-spike.ostc.intel.com> Message-Id: <20251103234437.A0532420@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Dave Hansen Separate __user pointer variable declaration from kernel one. There are two 'kvm_cpuid2' pointers involved here. There's an "input" side: 'td_cpuid' which is a normal kernel pointer and an 'output' side. The output here is userspace and there is an attempt at properly annotating the variable with __user: struct kvm_cpuid2 __user *output, *td_cpuid; But, alas, this is wrong. The __user in the definition applies to both 'output' and 'td_cpuid'. Sparse notices the address space mismatch and will complain about it. Fix it up by completely separating the two definitions so that it is obviously correct without even having to know what the C syntax rules even are. Signed-off-by: Dave Hansen Fixes: 488808e682e7 ("KVM: x86: Introduce KVM_TDX_GET_CPUID") Reviewed-by: Rick Edgecombe Cc: Xiaoyao Li Cc: Sean Christopherson Cc: Paolo Bonzini Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: x86@kernel.org Cc: "H. Peter Anvin" Cc: "Kirill A. Shutemov" Cc: Rick Edgecombe Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Kiryl Shutsemau Reviewed-by: Xiaoyao Li --- b/arch/x86/kvm/vmx/tdx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN arch/x86/kvm/vmx/tdx.c~tdx-sparse-fix-3 arch/x86/kvm/vmx/tdx.c --- a/arch/x86/kvm/vmx/tdx.c~tdx-sparse-fix-3 2025-11-03 15:11:26.773525519= -0800 +++ b/arch/x86/kvm/vmx/tdx.c 2025-11-03 15:11:26.782526277 -0800 @@ -3054,7 +3054,8 @@ static int tdx_vcpu_get_cpuid_leaf(struc =20 static int tdx_vcpu_get_cpuid(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *c= md) { - struct kvm_cpuid2 __user *output, *td_cpuid; + struct kvm_cpuid2 __user *output; + struct kvm_cpuid2 *td_cpuid; int r =3D 0, i =3D 0, leaf; u32 level; =20 _ From nobody Sun Dec 14 11:14:56 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4EA383090E4; Mon, 3 Nov 2025 23:44:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762213482; cv=none; b=kR8cJPPoiGVeZES0o8CLxfVNDShUA38jLu0JOYVHmLGeIOJ3oUTprFpODjlfqMTy/ucTFgz3Ac2mwTzOZD6RWCEldi5ZtMmRtY2SA5sCwyWw4g5se5hOgEuc9sdfXBvP8rDfN5yOFsjRmKKj6EckQHtjdrjgqVaDNPFgMo/R/Fc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762213482; c=relaxed/simple; bh=plT6RDGZ55kW9Y/hyCWee00KU8pk6DzkUuw9fe7+RZk=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=QRAqP0P3L1BLnBYrrPvzzT8IX65o7Dxh9RbyCpCQeIooy2VmurH0/r67X9MKejX+cF8a8uCBQ5/zVgYSXxEMDeYd8PhdxagoQOUhwM1Z+pklVeqb82UcRYQtWtWnD8jiWPhYygpQnltK20n6KytW3SKVb+4v78+CsAfPyBurKBQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Xo4iRbnf; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Xo4iRbnf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1762213480; x=1793749480; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=plT6RDGZ55kW9Y/hyCWee00KU8pk6DzkUuw9fe7+RZk=; b=Xo4iRbnftUeoE6ORGymoNrh6qJrO1U4rrQwNsJ1dhI8MB4h9l3VGizsX W0xu6N28GaWEUWM1Dx2fKKsRe02I4jd28JZDHY2ZfQbrC1JtCP1s9l5x6 onYBNzbm1gkyw+uHL6RONUT/Fm7KU09CwL7SqcrwBIw+aLUd1okkFXUwp UsASBcWIh+Ozirs2NequvfzNTuuIIddbNQ0dFWa2HVRTpA4AXZztigAjY 5OroEU4cZnlh8nO9oFp3QG40W8kW1MiD6Htl9u9cmI8MuI8AxukG5JbRu 3/HtbTEn4wXLyV9g1T+xkDf9jXIpYzDyFUi9d0YfOF1aNpurZ30dIZkSw w==; X-CSE-ConnectionGUID: zJ8Rb6ReROW0Xjz+AqO98g== X-CSE-MsgGUID: 0nZXw3QXQKaO7y7lTv41qA== X-IronPort-AV: E=McAfee;i="6800,10657,11602"; a="64396852" X-IronPort-AV: E=Sophos;i="6.19,277,1754982000"; d="scan'208";a="64396852" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2025 15:44:40 -0800 X-CSE-ConnectionGUID: s9zKKyDHTzqkxTSoMGGfKg== X-CSE-MsgGUID: VSEh5AI/QHCY/TJA6M+qDQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,277,1754982000"; d="scan'208";a="186948466" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa007.jf.intel.com with ESMTP; 03 Nov 2025 15:44:39 -0800 Subject: [v2][PATCH 2/2] x86/virt/tdx: Fix sparse warnings from using 0 for NULL To: linux-kernel@vger.kernel.org Cc: Dave Hansen , Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , kvm@vger.kernel.org, Paolo Bonzini , Rick Edgecombe , Sean Christopherson , Thomas Gleixner , x86@kernel.org, Xiaoyao Li From: Dave Hansen Date: Mon, 03 Nov 2025 15:44:39 -0800 References: <20251103234435.0850400B@davehans-spike.ostc.intel.com> In-Reply-To: <20251103234435.0850400B@davehans-spike.ostc.intel.com> Message-Id: <20251103234439.DC8227E4@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Dave Hansen Stop using 0 for NULL. sparse moans: ... arch/x86/kvm/vmx/tdx.c:859:38: warning: Using plain integer as NULL po= inter for several TDX pointer initializations. While I love a good ptr=3D0 now and then, it's good to have quiet sparse builds. Signed-off-by: Dave Hansen Fixes: a50f673f25e0 ("KVM: TDX: Do TDX specific vcpu initialization") Fixes: 8d032b683c29 ("KVM: TDX: create/destroy VM structure") Reviewed-by: Rick Edgecombe Cc: Xiaoyao Li Cc: Sean Christopherson Cc: Paolo Bonzini Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: x86@kernel.org Cc: "H. Peter Anvin" Cc: "Kirill A. Shutemov" Cc: Rick Edgecombe Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Kiryl Shutsemau Reviewed-by: Xiaoyao Li --- b/arch/x86/kvm/vmx/tdx.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff -puN arch/x86/kvm/vmx/tdx.c~tdx-sparse-fix-1 arch/x86/kvm/vmx/tdx.c --- a/arch/x86/kvm/vmx/tdx.c~tdx-sparse-fix-1 2025-11-03 15:11:28.177643833= -0800 +++ b/arch/x86/kvm/vmx/tdx.c 2025-11-03 15:11:28.185644508 -0800 @@ -856,7 +856,7 @@ void tdx_vcpu_free(struct kvm_vcpu *vcpu } if (tdx->vp.tdvpr_page) { tdx_reclaim_control_page(tdx->vp.tdvpr_page); - tdx->vp.tdvpr_page =3D 0; + tdx->vp.tdvpr_page =3D NULL; tdx->vp.tdvpr_pa =3D 0; } =20 @@ -2642,7 +2642,7 @@ free_tdcs: free_tdr: if (tdr_page) __free_page(tdr_page); - kvm_tdx->td.tdr_page =3D 0; + kvm_tdx->td.tdr_page =3D NULL; =20 free_hkid: tdx_hkid_free(kvm_tdx); @@ -3016,7 +3016,7 @@ free_tdcx: free_tdvpr: if (tdx->vp.tdvpr_page) __free_page(tdx->vp.tdvpr_page); - tdx->vp.tdvpr_page =3D 0; + tdx->vp.tdvpr_page =3D NULL; tdx->vp.tdvpr_pa =3D 0; =20 return ret; _