Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp3300388ioa; Tue, 26 Apr 2022 00:22:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWTztb7zSvoR+G+5SRkfrcnlod73VHM2J0GkgL3nLs43A9c7Z5Q04qh3UHJF7KQv3mpdsU X-Received: by 2002:aa7:8094:0:b0:505:b544:d1ca with SMTP id v20-20020aa78094000000b00505b544d1camr23059971pff.26.1650957727505; Tue, 26 Apr 2022 00:22:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650957727; cv=none; d=google.com; s=arc-20160816; b=cvZsS/JjDEVhl5CbhrIhoC8eO79Cy4SvB2yK1a+LrzVdAoxQgBkz+HHCjKzBxhUQDy 5C84YcVVTi14Gffpyt5gMVlLZgoCjuLgkmA8xF9qx76BUTIE1hzjxmBPCSevjnRtC+uc s6F91V9zM3yL2/qi2UBvalWtACB/QibWg5AP0jaEAj8TYy5xJzBBtNCsQ03dNi7FYd8L ecuN+dseiXOZ8LJ9i3rijz3coEkgrB/bxY566Xteh3qiFU1S7VqYPWetkR4wLhiWB3WD 1cdpBRM+H1aleRaBa+UEuJfWgJIim2F3oK2J8z797A7DZVL1U/wlIanrwo4YxoIHhGBU f+hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=CZnLpvxQl09Dm/cWN78/JqIOE98D3AYwYhVCfqRlX5s=; b=JGgSbqykBP41vlF7U7uqMtLJmPR30W9HAqonH0QyvMp/2ZUNGlw5h3Jn/3/y4d+AtS 2lZ7s6xsLuxz7SEn0tJstjex6dfocvDopY+dZQcPV5k8AAFgo7BHafk4Jj8iNsK8wkbL Wth+Us4sxUnQJebgOMGzNCI503VgSfg7MPtX5y1uHip9VpgXQRNv6rsofaEJCWkVysk1 Ha7dCpFIdBmo1DRG7W0D5FcEwTy7emB4II0St9SHuLWbaRbuHt9XjPebEMdSJ08Bb0bP FHmIf1YbDAZf5W1Mrb+bw+xKuhVSepoKPZmNdvCqEaKUgSi7IGxNa3bvLN0cZoIDOL7F P9dg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=dsS4DZ8c; 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 br8-20020a056a00440800b0050d4be3b418si2502214pfb.188.2022.04.26.00.21.53; Tue, 26 Apr 2022 00:22:07 -0700 (PDT) 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=dsS4DZ8c; 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 S239066AbiDZAIi (ORCPT + 99 others); Mon, 25 Apr 2022 20:08:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234498AbiDZAIh (ORCPT ); Mon, 25 Apr 2022 20:08:37 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7603835857; Mon, 25 Apr 2022 17:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650931531; x=1682467531; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=JiKB+A2uaXqkRjPBW7uR78DBY0vfODCV29cJBCN4srM=; b=dsS4DZ8ch0kQ5JrrDXvfNPqzqZH8tz8UChbjqdnE9hbQQ9q+2Hi4M2h4 uAYH3fZ92n0guhIcQu5C4UBuY3TnOQh0Ke18LUtkHXyjiOYJxJqmPpPW2 sDL9smOYrdoRDd6zCo6QVwxIMTbyII7TYEdftjr25mvIF/oIa0CdFZfna TdgWS2H77kHXazV71OC5b0XVyH6hL0Yf4M70xLPyOTdawY2oyqFHdhHUv Pgiva8d3VNAZJKnng69gvNV2rjADFGy63iGv00kaRYxGfqBBwqSU1pZyO bmnvUn2IvFfwLfUT5MhK0rkRcqLmmpcifqqCkST2/gh/lCl3mm6JFllXK g==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="325886296" X-IronPort-AV: E=Sophos;i="5.90,289,1643702400"; d="scan'208";a="325886296" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 17:05:30 -0700 X-IronPort-AV: E=Sophos;i="5.90,289,1643702400"; d="scan'208";a="616739283" Received: from begriffi-mobl2.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.254.0.169]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 17:05:26 -0700 Message-ID: <7887db8b5108b8dc9bd35868db561badca060b51.camel@intel.com> Subject: Re: [PATCH v3 09/21] x86/virt/tdx: Get information about TDX module and convertible memory From: Kai Huang To: Sathyanarayanan Kuppuswamy , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, dave.hansen@intel.com, len.brown@intel.com, tony.luck@intel.com, rafael.j.wysocki@intel.com, reinette.chatre@intel.com, dan.j.williams@intel.com, peterz@infradead.org, ak@linux.intel.com, kirill.shutemov@linux.intel.com, isaku.yamahata@intel.com Date: Tue, 26 Apr 2022 12:05:23 +1200 In-Reply-To: <8972b2ac-c786-8ff5-74fc-040cd4d81c86@linux.intel.com> References: <145620795852bf24ba2124a3f8234fd4aaac19d4.1649219184.git.kai.huang@intel.com> <8972b2ac-c786-8ff5-74fc-040cd4d81c86@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, 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 > > > +} > > + > > +static int sanitize_cmrs(struct cmr_info *cmr_array, int cmr_num) > > Since this function only deals with tdx_cmr_array, why pass it > as argument? I received comments to use cmr_num as argument and pass tdx_cmr_num to sanitize_cmrs() and finalize it at the end of this function. In this case I think it's better to pass tdx_cmr_array as argument. It also saves some typing (tdx_cmr_array vs cmr_array) in sanitize_cmrs(). > > > +{ > > + int i, j; > > + > > + /* > > + * Intel TDX module spec, 20.7.3 CMR_INFO: > > + * > > + * TDH.SYS.INFO leaf function returns a MAX_CMRS (32) entry > > + * array of CMR_INFO entries. The CMRs are sorted from the > > + * lowest base address to the highest base address, and they > > + * are non-overlapping. > > + * > > + * This implies that BIOS may generate invalid empty entries > > + * if total CMRs are less than 32. Skip them manually. > > + */ > > + for (i = 0; i < cmr_num; i++) { > > + struct cmr_info *cmr = &cmr_array[i]; > > + struct cmr_info *prev_cmr = NULL; > > Why not keep declarations together at the top of the function? Why? They are only used in this for-loop. > > > + > > + /* Skip further invalid CMRs */ > > + if (!cmr_valid(cmr)) > > + break; > > + > > + if (i > 0) > > + prev_cmr = &cmr_array[i - 1]; > > + > > + /* > > + * It is a TDX firmware bug if CMRs are not > > + * in address ascending order. > > + */ > > + if (prev_cmr && ((prev_cmr->base + prev_cmr->size) > > > + cmr->base)) { > > + pr_err("Firmware bug: CMRs not in address ascending order.\n"); > > + return -EFAULT; > > + } > > Since above condition is only true for i > 0 case, why not combine them > together if (i > 0) {...} It will make an additional ident for the above if() {} to check prev_cmr and cmr. I don't see it is better? -- Thanks, -Kai