From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E241C4321E for ; Fri, 2 Dec 2022 17:26:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233743AbiLBR0B (ORCPT ); Fri, 2 Dec 2022 12:26:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233609AbiLBRZ6 (ORCPT ); Fri, 2 Dec 2022 12:25:58 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7F5310A1; Fri, 2 Dec 2022 09:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670001957; x=1701537957; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=UAxenKvkDH4wwIwcRyi4RJ3isQRBDPM97pG5KlxBFRI=; b=BuqcTn23yL+2Nua+JdsV9MJnJWaDlZfl/+Yjy7YedpNFl3/ZHYEIWFJJ UOz2BZaz/PjOlZjiQpOik0qwobA7CHUzgOO1CGPrVstc33TruzZoxgBYn ZlZbE5AaWUXx4Y+T5yHf1w6stEGrKWekIta+IFm+YwbHxXud7QEmMj5v/ B5EvOLSkyV0p1ROkRM7hXjxJp81S3uJ/6hshVQKNSg7wTdFOqyFmqBYuS J59CqPghzEdg97EKnwzUhbO/lUdJF46vAAVLAmZcXRQaQ5lZLHMmx1l7a zsh89pMN9Af6ueNzqpgMemdr+QQKwi38/YOWhAFeeNlcWljJa3RAuzihY w==; X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="402282411" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="402282411" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 09:25:57 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="638813719" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="638813719" Received: from rsnyder-mobl.amr.corp.intel.com (HELO [10.209.68.71]) ([10.209.68.71]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 09:25:56 -0800 Message-ID: <0decd051-a247-3f92-2df7-c7684ed18c75@intel.com> Date: Fri, 2 Dec 2022 09:25:56 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v7 09/20] x86/virt/tdx: Get information about TDX module and TDX-capable memory Content-Language: en-US To: "Huang, Kai" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Luck, Tony" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Christopherson,, Sean" , "Chatre, Reinette" , "pbonzini@redhat.com" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "peterz@infradead.org" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "Shahar, Sagi" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <850e0899-d54e-6a49-851e-56f4d353905c@intel.com> <57af0b96f8a827828b1d64031774962972bfb060.camel@intel.com> <1c6580f7-3abb-03ba-dd98-367ddb9bf23b@intel.com> <7be59cd82bc3f3c26e835980eb74a8d92c6d67d6.camel@intel.com> From: Dave Hansen In-Reply-To: <7be59cd82bc3f3c26e835980eb74a8d92c6d67d6.camel@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/2/22 03:19, Huang, Kai wrote: > Probably I forgot to mention the "r9" in practice always returns 32, so there > will be empty CMRs at the tail of the cmr_array[]. Right, so the r9 value is basically useless. I bet the code gets simpler if you just ignore it. >> But we can also do nothing here, but just skip empty CMRs when comparing the >> memory region to it (in next patch). >> >> Or, we don't even need to explicitly check memory region against CMRs. If the >> memory regions that we provided in the TDMR doesn't fall into CMR, then >> TDH.SYS.CONFIG will fail. We can just depend on the SEAMCALL to do that. > > Sorry to ping, but do you have any comments here? > > How about we just don't do any check of TDX memory regions against CMRs, but > just let the TDH.SYS.CONFIG SEAMCALL to determine? Right, if we screw it up TDH.SYS.CONFIG SEAMCALL will fail. We don't need to add more code to detect that failure ourselves. TDX is screwed either way.