From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.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 013B4319859 for ; Tue, 13 Jan 2026 03:58:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768276728; cv=none; b=Q/piDQggAa1GXP9FqQV0gvH4/ABG6TzzrwVYn38N6CsX6FqUlY3KAqRd1AfV2eBEtK8Bb6lcdhzD28ctTM4qAugoY8vUZClsI4Uhdwx690KcGoK1iF2SbQj5CY1WGWarHQ6v5vUTh2euE6iIBLIkLBv8NDLw31LRvmjIByxPVaY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768276728; c=relaxed/simple; bh=FvItaEemTJxbw1gAV4qb83fnhQyNwytQF67ujmNQzVQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pNrVQBpXn7c5jPzv+qA+CW5VM4fp+YYiaj22iCEsK5Kq1mE34Km9PYIT9WLwz3Wu2gJ4uT8rAk9vEytNAM3f6q/CJYoQPWRYl0YySyxpN3ds7s7HMF+aSDkgEJ6T+0N1VXv9JlSpTHtbaQbbinpn/70id6rh5lHAUZQ4BxEiwbg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MIc0Oj53; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MIc0Oj53" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768276727; x=1799812727; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=FvItaEemTJxbw1gAV4qb83fnhQyNwytQF67ujmNQzVQ=; b=MIc0Oj53QS83U8PE7CBRojyi/HdOpoq4LH8mJVOIxFc70cdT3X0dEdeM OMfa2fDZ2tyWQ+iBNTg1pLr2hFAVblRNy1LpV8bpWE/UnAnj9JBL9qE/c FrwQAOlqDXKPYr8eZFhvpYnS9bxfecw2nzZ1HMxYtMwKPuthZsgCQ36Sw Fc2FT9vRLijSViUNZVJolDZsLIvGxjXaQj63RlnZoH0AAGyfMkbS6g1kf V1P2PDNaAHbgi5h97tBVmQphAPUMqr+QJ6Oijx3iAwqijQxTikD2uNtHc 7jnaWF2viamAGy19AjSsK0OyxK6/s1P7awKf6UgLTyREd5NmAo2b+PnwJ Q==; X-CSE-ConnectionGUID: IKmq3aW7SyqpeUyYI8RpBA== X-CSE-MsgGUID: fzzV0uEsS+KDewR5+WUVfg== X-IronPort-AV: E=McAfee;i="6800,10657,11669"; a="69543047" X-IronPort-AV: E=Sophos;i="6.21,222,1763452800"; d="scan'208";a="69543047" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2026 19:58:46 -0800 X-CSE-ConnectionGUID: fZzLhQSWRKuZw3KxbiK8Gw== X-CSE-MsgGUID: ArLBE187T4+gukmDQNcdag== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,222,1763452800"; d="scan'208";a="204559380" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.240.173]) ([10.124.240.173]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2026 19:58:42 -0800 Message-ID: Date: Tue, 13 Jan 2026 11:58:39 +0800 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve TDX module version To: Xu Yilun , Dave Hansen Cc: Vishal Verma , linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, x86@kernel.org, Chao Gao , Dan Williams , Kai Huang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe References: <20260109-tdx_print_module_version-v2-0-e10e4ca5b450@intel.com> <20260109-tdx_print_module_version-v2-1-e10e4ca5b450@intel.com> <93ab41bc-91bf-405a-84c4-6355a556596d@intel.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/13/2026 10:56 AM, Xu Yilun wrote: > On Mon, Jan 12, 2026 at 06:56:58AM -0800, Dave Hansen wrote: >> On 1/11/26 18:25, Xiaoyao Li wrote: >>> ... I know it's because minor_version has the least field ID among the >>> three. But the order of the field IDs doesn't stand for the order of the >>> reading. Reading the middle part y of x.y.z as first step looks a bit odd. >> >> I wouldn't sweat it either way. Reading 4, 3, 5 would also look odd. I'm >> fine with it as-is in the patch. > > I prefer 3, 4, 5. The field IDs are not human readable hex magic so > should take extra care when copying from excel file to C file manually, > A different list order would make the code adding & reviewing even > harder. I guess eventually we will introduce MACROs for these magic numbers to make the code more readable given that the decision is no longer auto-generate the code by the script? Though I'm not sure when that will happen.