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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CB8BC43217 for ; Mon, 28 Nov 2022 22:56:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E00E46B0071; Mon, 28 Nov 2022 17:56:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB0726B0072; Mon, 28 Nov 2022 17:56:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C782B6B0073; Mon, 28 Nov 2022 17:56:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B886B6B0071 for ; Mon, 28 Nov 2022 17:56:31 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9050E1A0624 for ; Mon, 28 Nov 2022 22:56:31 +0000 (UTC) X-FDA: 80184361782.03.C928212 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf28.hostedemail.com (Postfix) with ESMTP id B4B43C000E for ; Mon, 28 Nov 2022 22:56:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669676190; x=1701212190; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=lMph/tM1XZPPmKJoB9xyc4L8wuSBzaj6cHmnYu1ENrg=; b=dDgdC0Vb4OZndpAXUWc05u1rm2gLL5SUh4G4uJNqOnsOvQrAgm8LXt10 /ivGr4JP1DLRn0YLqXYsHF0fssVQHMhzypp1dKRgxfQLQqBsAdMNhA5N8 7EIQsU0yjqrbmIF0Db6vC8on4ncwlFcGYhYvEk2zyTtgNslJHFQr6CCRK tdn1gT3wtmfcN8hHo4s3NcvbLXjZWDKFPoHidx1/kmwtOD3sDUW6T+b8i qWwiUr58COpTnDJRGOIFXN/52aeQXrJJmrNsWi/9f7EROjZfX8T0xLalF pwYVvkqD/OtZXkRqY4dgT0CXJJAiByZaoqv2+Ok+dpBxfXZPqbQuTsKgl w==; X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="401253079" X-IronPort-AV: E=Sophos;i="5.96,201,1665471600"; d="scan'208";a="401253079" 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669676191; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0DLt6O0aaWwxxsnhE8RtXqow60aaUga/quCEJ35acsA=; b=SA3+Ai2ZucOp5TxzeeeKCN1Wy9LfV7gxmdcTvrRijzLQHNbSCyt639gpvAbkcISThNa+km mjw8NbO0VKPlf0EzKNuBOI+gLqyvL5kQZ2BTYy8KqtQhrIhsBsVxSCW1wo05rq1h63Vtvl r0voHGU9aUm1kAQvcEcOeVbbhokbkQ0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=dDgdC0Vb; spf=pass (imf28.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669676191; a=rsa-sha256; cv=none; b=s4suz/rfBYrTm65fnTqodWio08g6AU8QJbwGB5B+u09dFXdaKtL5w3WC0wv0EDJL2cJ0gJ S3WYf56L9OOgMoj4WxHEint0JxxXp95OMOjuhydcs9UV1ohaBXmK7jxvj4HJAcY73pxF/S ExYU51gy52d8TzjJHEyzTFOx1Ya9zdQ= X-Stat-Signature: 9t11se4jopyaj545psoej6cdk9bdnset X-Rspam-User: X-Rspamd-Queue-Id: B4B43C000E X-Rspamd-Server: rspam11 Authentication-Results: imf28.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=dDgdC0Vb; spf=pass (imf28.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1669676190-146945 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.