Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2429589rwb; Fri, 2 Dec 2022 09:36:57 -0800 (PST) X-Google-Smtp-Source: AA0mqf79tt/X/RgqD4bQfzwdwkdNoK72uKQjfNxc1CobnEKVyuwiEfIPg0ECaqd3uys+UNEcTfx8 X-Received: by 2002:a05:6402:d78:b0:46b:a177:9d84 with SMTP id ec56-20020a0564020d7800b0046ba1779d84mr13839756edb.134.1670002617251; Fri, 02 Dec 2022 09:36:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670002617; cv=none; d=google.com; s=arc-20160816; b=pdxwNrgoUZ6rA/5WYIWUNYOFbgOVzWd1vhZ/NiBVzcZivnA81ti94bWeJfNljXvtOM kx9NVsJdJmIXude+dql4SCaOUIZcXQ8ItZOU47waGJcpOKlfpINvK1zfvQzUazgG5kH1 cpLmM291TQ/T/xsgIMPfbF24r5VVTA8zsuGEcszXHZkCHvgrSJpHolEG0zVEyD96aHZ5 IPUUZyj5PfL1ZJK1tFFji1ZECtC9dy1dZ/okKdR5Mvym7ajhjDUk5enVs0X9Xiq3nQeo lI3hsACSgNq23CyB9GKnc9HZPXwMHulmIhVMzgWUWsx70yom/bQs4XX/zqGAlX77Pn3s s5NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=HEJjqcmlCHU/B7vO/08fUvt2qIFYiSzD5QJbbNTL810=; b=f7uNcJW5Krte0AzWKgnF+cOOoOkSDJD7sqklhiZQFHZR2GA2330seIMifdjEy+JG8C +rNHOudNe0mL1WJRTUq6QYRT2jxHdnRq4syhLceGBMvakuBGe2YTT8egL6JRtCd10BGJ CrIMvBdC7XrTg+ct9M1leSllqpszIR0n8gSDNt9yzOA446d/wsgqlOQnNq3FhTf97czb GEg24Zk6mCeSq+ZejZj3wdmk1QcRTnPw0cugzL8x8LtwSetVdB5x8pEBQWGauhOxApYb KqVMKkHzxzgPz9X0+O33IwYk4CClVQ6esauqEcKV5WFwsfQoEhWcaahtYNkef4VGJdii ykbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=BuqcTn23; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i16-20020a0564020f1000b0046b2840ca3dsi975051eda.474.2022.12.02.09.36.36; Fri, 02 Dec 2022 09:36:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=BuqcTn23; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233693AbiLBR0A (ORCPT + 83 others); Fri, 2 Dec 2022 12:26:00 -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 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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.