Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp15696981rwb; Mon, 28 Nov 2022 15:05:44 -0800 (PST) X-Google-Smtp-Source: AA0mqf5KC95neffh+NwX/5adn/SH+D2a0Qmf4E6V2RDb1jyObBMR5ugTZE8iISqi3QJLndMri0OF X-Received: by 2002:a17:902:e849:b0:17a:aca0:e295 with SMTP id t9-20020a170902e84900b0017aaca0e295mr47636739plg.3.1669676744595; Mon, 28 Nov 2022 15:05:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669676744; cv=none; d=google.com; s=arc-20160816; b=cLMhBF5s+4607IU1CPr4gOnlWwgTGrVbFEaj3y9GQS58JewoW8zfVpZqo7czhpqkie HHyFzpgVdEgFziubu/y5cqYBPiE1+BnXoCXpKgd06veKiZF0a7pgy5Jf1Fy2G/98gPRA uAqq8zsFpPldrK6uRgUMDgMfMN5AGOWcySLK4fV/cM0Pp9CEgqgOuxXpBU7Q6vvbZ9m1 +Z9Uulq1SJvLAB6dbj9kl+SmgBStKmCvwq3odR41VkI1nfG0E5lZvVsPxFpmT8UQAEtb co1BRAJhb3/BrVNII+07ybo8MhpPj/rKGH4T7vCAXkRFUuYPk7TQVguQ0eJe8cL5hrxN QL/g== 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=0DLt6O0aaWwxxsnhE8RtXqow60aaUga/quCEJ35acsA=; b=u3t+D7XzazjWejuhKpEE5DyegNKeUo3AyAWtLX/nvNJ9vJuBG7v+KKXLBGH44g/Q9I 7NNyeF/Ok2nEPAawGnnOiabDS+nuz4XSnPcOS0yBnQGk6yadXTuLnB+0aWbJZg08lmZe UvCciEMPn2rhRXPbiB1jIKLIYheAmhtRPGMMeQYRCsWR9BnFbS5lDnqxUyH8PPKxQOWV 7kpMPoR9pJK0+F6qO3zA/yMFWvwSa63+ZugWksKyJNfYpsMBAcoAC+2dFElIqvSZ3g6q DAuswfqHXpm9h8qYkjoP6yThjRPIfIKyjcGLjgl7rtOT981ZyaRcJcktD5J1HLWcjK02 cHUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jjyU6Ifa; 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 d188-20020a6336c5000000b00477cead7cd1si13687407pga.644.2022.11.28.15.05.33; Mon, 28 Nov 2022 15:05:44 -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=jjyU6Ifa; 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 S233537AbiK1W4c (ORCPT + 83 others); Mon, 28 Nov 2022 17:56:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229501AbiK1W4a (ORCPT ); Mon, 28 Nov 2022 17:56:30 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8DB12A42F; Mon, 28 Nov 2022 14:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669676189; x=1701212189; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=lMph/tM1XZPPmKJoB9xyc4L8wuSBzaj6cHmnYu1ENrg=; b=jjyU6IfanORkYFMfEWh91jU0cd8609t0K+X9kVDB0Ib8cRTkhvrx723C T5DWSLz9MRzbMFLNQdi9FGnR5ZYMeqqmlGaCQUXaDkooWtSzRjwvWYl1I GUXfBSWvrdJ1xkHV/ouc6rgb+FskmMy5UnYJhs2UyLeRdandnEdEjZHrZ kI5v+tk0R4IKTkOrlqOcpqIxUSVbo9jofaKvTh54i1MyKgzJRm8h9vMNO 1RxBqdDDM/rYj0bpv6SA3CQ8lvrtrr7b0AbPFqGJmcgA91J5m6ihiF+XJ icQtidZdP5+gCnvLK7+rX3wnfnnPASBvtcBtgbNL25ULZ+KyvtUAoiQCe g==; X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="401253078" X-IronPort-AV: E=Sophos;i="5.96,201,1665471600"; d="scan'208";a="401253078" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 14:56:23 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="888612395" X-IronPort-AV: E=Sophos;i="5.96,201,1665471600"; d="scan'208";a="888612395" Received: from nroy-mobl1.amr.corp.intel.com (HELO [10.212.209.4]) ([10.212.209.4]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 14:56:22 -0800 Message-ID: <44e28b2e-833d-4ad3-542d-b2fae41dbf97@intel.com> Date: Mon, 28 Nov 2022 14:56:20 -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 13/20] x86/virt/tdx: Allocate and set up PAMTs for TDMRs 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" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "peterz@infradead.org" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <74723e2b-3094-d04b-aed7-2789268b00ab@intel.com> <1e45748f-0de1-39aa-7e0f-7596ff813302@intel.com> From: Dave Hansen In-Reply-To: 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 11/28/22 14:48, Huang, Kai wrote: >> Maybe even a little ASCII diagram about the different tmb configurations >> that this can find: >> >>> TDMR1 | TDMR2 | >> |---tmb---| >> |tmb| >> |------tmb-------| <- case 3) >> |------tmb-------| <- case 4 > Thanks for the diagram! > > But IIUC it seems the above case 3) and 4) are actually not possible, since when > one TDMR is created, it's end is always rounded up to the end of TMB it tries to > cover (the rounded-up end may cover the entire or only partial of other TMBs, > though). OK, but at the same time, we shouldn't *STRICTLY* specialize every single little chunk of this code to be aware of every other tiny little implementation detail. Let's say tomorrow's code has lots of TDMRs left, but fills up one TDMR's reserved areas and has to "split" it. Want to bet on whether the person that adds that patch will be able to find this code and fix it up? Or, say that the TDMR creation algorithm changes and they're not done in order of ascending physical address. This code actually gets easier and more obvious if you ignore the other details.