Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp8137989rwb; Wed, 23 Nov 2022 16:16:12 -0800 (PST) X-Google-Smtp-Source: AA0mqf6KbtldMH9tllf3kZNL2tg8fGt+KRU6xlOTiyNaQi/yoEz6HVQomsrPp5uR8Xo7qdH30lCg X-Received: by 2002:a17:906:5ad1:b0:7b2:b15e:3242 with SMTP id x17-20020a1709065ad100b007b2b15e3242mr22981270ejs.672.1669248972362; Wed, 23 Nov 2022 16:16:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669248972; cv=none; d=google.com; s=arc-20160816; b=Llv1QjVxCF5aqKXJ/xPPhUVBMCPgtipQQfj0GLmYljsjqdbZdxMpFFKMFjwDinJq1X QBICBLBsKh+pj9iV7nwZiCoddv6u7fSzZSeCNi+b3UlQuwpkGl2c6Rt96TL8Zv27Nuhg 0b9s9xEhD5oDiBwh874Iat/sPrSNS5wazD2pr2oHKzJ6aQQoqQbPMnVzFQ/TglBf3nRe T6Bs23tnkKAYdXYYP9DoiGfyr5hI2BXAswA6/+wx/IMLhYURSxPadqmwxINhCeKDKx7O tccEf5FoSk2qpaRdcucrTY5zc3hrnESyvyUozqmI1TVZsPAKcXviJpRMZ8GBF2znCgMf MwRw== 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=PelLGl3ySBdlVI92lqLNw6Vuf4qIev2lVZ0JveaDh7I=; b=EMQLKvv1hm0JqyZs4ZmCUKZEAPGjdW9+IwqUWC/XtVbQiQMbAKeze2Ezaw4Y+wFqcz y27A8XGvOu2lq/NjfKHUFo7iMADeD8l9H+uO1lb7DuFQcE7A54xFwv9CEkFtjEI2ihjP Yg5o3Xn9PnBaeuLFrvaiL9Ejtwxqc0W9o+uVIoAel4MpdgKcP3Sv3UXmn8FMtIppKpV9 ruOXzm2aE0NAK24QsOdwgsotOZeQmyY17a8WfJT8O0dePgdERMnHDGOthMu21tLNiVVk bwTUwD0lF++zGcfrpZMEGbAVVGvvKxa49HBZWmSGwy9NC52ay23mUXwvGeGSxpF4CJIx AoTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nlFFdy7p; 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 tz14-20020a170907c78e00b0077ef3eeca17si3944385ejc.155.2022.11.23.16.15.51; Wed, 23 Nov 2022 16:16:12 -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=nlFFdy7p; 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 S230012AbiKWXj0 (ORCPT + 88 others); Wed, 23 Nov 2022 18:39:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229884AbiKWXjX (ORCPT ); Wed, 23 Nov 2022 18:39:23 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73212DAD39; Wed, 23 Nov 2022 15:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669246761; x=1700782761; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=NbNzIvJel5W7dEOjelcpJ9WyJAs1Bi0d1O8jBfYAwTs=; b=nlFFdy7p40A3JnQU53MtMU/YBAwLyF8WGHjHEWJNgwzuwkKgzCpFic+O SNJMFiY7eie9CUb5ww9AY+rArbdErTTuK1DmSKGwpq2+L7NskMEspp2uq A3n8lKbFw7sN4l+Oq06MMfpOWtS3972wmYSmqc00+Z0h4k2KyuYloM/u+ YL61atCMcj4Woqz9u/HlEbE32AgHdHPCpFuyXa9V5x4PSMva4tSULvo/W yJRTMSUBBSsPieqxLJlzbvZ46Ef6Vs9lAEdmdym3q1Uw0Bu7AXzHvjnZH OgOb0TexmLzp1whkKoxXMRug8oIuhrnsgIdDcwkB0qv41P8BcDn0Ro9X3 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10540"; a="315330094" X-IronPort-AV: E=Sophos;i="5.96,187,1665471600"; d="scan'208";a="315330094" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2022 15:39:21 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10540"; a="674887505" X-IronPort-AV: E=Sophos;i="5.96,187,1665471600"; d="scan'208";a="674887505" Received: from vcbudden-mobl3.amr.corp.intel.com (HELO [10.212.129.67]) ([10.212.129.67]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2022 15:39:20 -0800 Message-ID: <5526fedd-fa54-0ad2-f356-94b167e6e290@intel.com> Date: Wed, 23 Nov 2022 15:39:19 -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 14/20] x86/virt/tdx: Set up reserved areas for all TDMRs Content-Language: en-US To: Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, kirill.shutemov@linux.intel.com, ying.huang@intel.com, reinette.chatre@intel.com, len.brown@intel.com, tony.luck@intel.com, peterz@infradead.org, ak@linux.intel.com, isaku.yamahata@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com References: <5a5644e691134dc72c5e3fb0fc22fa40d4aa0b34.1668988357.git.kai.huang@intel.com> From: Dave Hansen In-Reply-To: <5a5644e691134dc72c5e3fb0fc22fa40d4aa0b34.1668988357.git.kai.huang@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 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,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 tdmr_set_up_memory_hole_rsvd_areas(struct tdmr_info *tdmr, > + int *rsvd_idx) > +{ This needs a comment. This is another case where it's confusing to be passing around 'struct tdmr_info *'. Is this *A* TDMR or an array? /* * Go through tdx_memlist to find holes between memory areas. If any of * those holes fall within @tdmr, set up a TDMR reserved area to cover * the hole. */ static int tdmr_populate_rsvd_holes(struct list_head *tdx_memlist, struct tdmr_info *tdmr, int *rsvd_idx) > + struct tdx_memblock *tmb; > + u64 prev_end; > + int ret; > + > + /* Mark holes between memory regions as reserved */ > + prev_end = tdmr_start(tdmr); I'm having a hard time following this, especially the mixing of semantics between 'prev_end' both pointing to tdmr and to tmb addresses. Here, 'prev_end' logically represents the last address which we know has been handled. All of the holes in the addresses below it have been dealt with. It is safe to set here to tdmr_start() because this function call is uniquely tasked with setting up reserved areas in 'tdmr'. So, it can safely consider any holes before tdmr_start(tdmr) as being handled. But, dang, there's a lot of complexity there. First, the: /* Mark holes between memory regions as reserved */ comment is misleading. It has *ZILCH* to do with the "prev_end = tdmr_start(tdmr);" assignment. This at least needs: /* Start looking for reserved blocks at the beginning of the TDMR: */ prev_end = tdmr_start(tdmr); but I also get the feeling that 'prev_end' is a crummy variable name. I don't have any better suggestions at the moment. > + list_for_each_entry(tmb, &tdx_memlist, list) { > + u64 start, end; > + > + start = tmb->start_pfn << PAGE_SHIFT; > + end = tmb->end_pfn << PAGE_SHIFT; > + More alignment opportunities: start = tmb->start_pfn << PAGE_SHIFT; end = tmb->end_pfn << PAGE_SHIFT; > + /* Break if this region is after the TDMR */ > + if (start >= tdmr_end(tdmr)) > + break; > + > + /* Exclude regions before this TDMR */ > + if (end < tdmr_start(tdmr)) > + continue; > + > + /* > + * Skip if no hole exists before this region. "<=" is > + * used because one memory region might span two TDMRs > + * (when the previous TDMR covers part of this region). > + * In this case the start address of this region is > + * smaller than the start address of the second TDMR. > + * > + * Update the prev_end to the end of this region where > + * the possible memory hole starts. > + */ Can't this just be: /* * Skip over memory areas that * have already been dealt with. */ > + if (start <= prev_end) { > + prev_end = end; > + continue; > + } > + > + /* Add the hole before this region */ > + ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, prev_end, > + start - prev_end); > + if (ret) > + return ret; > + > + prev_end = end; > + } > + > + /* Add the hole after the last region if it exists. */ > + if (prev_end < tdmr_end(tdmr)) { > + ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, prev_end, > + tdmr_end(tdmr) - prev_end); > + if (ret) > + return ret; > + } > + > + return 0; > +} > + > +static int tdmr_set_up_pamt_rsvd_areas(struct tdmr_info *tdmr, int *rsvd_idx, > + struct tdmr_info *tdmr_array, > + int tdmr_num) > +{ > + int i, ret; > + > + /* > + * If any PAMT overlaps with this TDMR, the overlapping part > + * must also be put to the reserved area too. Walk over all > + * TDMRs to find out those overlapping PAMTs and put them to > + * reserved areas. > + */ > + for (i = 0; i < tdmr_num; i++) { > + struct tdmr_info *tmp = tdmr_array_entry(tdmr_array, i); > + unsigned long pamt_start_pfn, pamt_npages; > + u64 pamt_start, pamt_end; > + > + tdmr_get_pamt(tmp, &pamt_start_pfn, &pamt_npages); > + /* Each TDMR must already have PAMT allocated */ > + WARN_ON_ONCE(!pamt_npages || !pamt_start_pfn); > + > + pamt_start = pamt_start_pfn << PAGE_SHIFT; > + pamt_end = pamt_start + (pamt_npages << PAGE_SHIFT); > + > + /* Skip PAMTs outside of the given TDMR */ > + if ((pamt_end <= tdmr_start(tdmr)) || > + (pamt_start >= tdmr_end(tdmr))) > + continue; > + > + /* Only mark the part within the TDMR as reserved */ > + if (pamt_start < tdmr_start(tdmr)) > + pamt_start = tdmr_start(tdmr); > + if (pamt_end > tdmr_end(tdmr)) > + pamt_end = tdmr_end(tdmr); > + > + ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, pamt_start, > + pamt_end - pamt_start); > + if (ret) > + return ret; > + } > + > + return 0; > +} > + > +/* Compare function called by sort() for TDMR reserved areas */ > +static int rsvd_area_cmp_func(const void *a, const void *b) > +{ > + struct tdmr_reserved_area *r1 = (struct tdmr_reserved_area *)a; > + struct tdmr_reserved_area *r2 = (struct tdmr_reserved_area *)b; > + > + if (r1->offset + r1->size <= r2->offset) > + return -1; > + if (r1->offset >= r2->offset + r2->size) > + return 1; > + > + /* Reserved areas cannot overlap. The caller should guarantee. */ > + WARN_ON_ONCE(1); > + return -1; > +} > + > +/* Set up reserved areas for a TDMR, including memory holes and PAMTs */ > +static int tdmr_set_up_rsvd_areas(struct tdmr_info *tdmr, > + struct tdmr_info *tdmr_array, > + int tdmr_num) > +{ > + int ret, rsvd_idx = 0; > + > + /* Put all memory holes within the TDMR into reserved areas */ > + ret = tdmr_set_up_memory_hole_rsvd_areas(tdmr, &rsvd_idx); > + if (ret) > + return ret; > + > + /* Put all (overlapping) PAMTs within the TDMR into reserved areas */ > + ret = tdmr_set_up_pamt_rsvd_areas(tdmr, &rsvd_idx, tdmr_array, tdmr_num); > + if (ret) > + return ret; > + > + /* TDX requires reserved areas listed in address ascending order */ > + sort(tdmr->reserved_areas, rsvd_idx, sizeof(struct tdmr_reserved_area), > + rsvd_area_cmp_func, NULL); Ugh, and I guess we don't know where the PAMTs will be ordered with respect to holes, so sorting is the easiest way to do this.