Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp234403iob; Mon, 2 May 2022 18:02:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPiMwuffn62flsMvzA5dT4UtZIo37bV0+uDoHl6Qm5avdwthWBFqTN6kxzAkJA64Er9d43 X-Received: by 2002:a17:902:6b0b:b0:158:f889:edd9 with SMTP id o11-20020a1709026b0b00b00158f889edd9mr14330463plk.122.1651539751400; Mon, 02 May 2022 18:02:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651539751; cv=none; d=google.com; s=arc-20160816; b=y/zrHGi5kz6lG2ImSBWIyBQCWwYWvQ7r6XlCeThVKQ7J8kb4JtPzI8posjNPpNG8VK G4jimgI+weNlaNGB2HS1vVt0ZBdcA+o0I3m6BMFCPORGHzASj213gwsKPDyHjS8aaFet ufE/az4AiWfpXfFT4r6pcxiD29EjrjEznfiLbfuTnM5rw8zrdilt9rc4CM3AJMKFzxkQ HndjGRjb2Rz+zOY/zk48Z7VJzhAjehWEgo3SmdLNN0C2im4FwZYf924jz36yXu8WGWkW tMfbXnlvw9HNGDlBRJFODD00DUDVb63Jw9QNgB2m6pMoNEvPsLy7SANWyOeLotwwQ3ge dy3Q== 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=0l8iV3Ovn62EryKpGJKfYKTSkqDt+1BSDByke6aubuE=; b=diA8+3/FopExa5JekSPCAhTPXHlsFIsYr0ziCHYsiKAsk/33m1/8KdK1IEuSWKtWEs 5DX9R3MAOcP9GOMqZfeaRiln72+4HowKGEUD5/CkB27h7ZG0tclnacw7RPr5BIdqUH0T ED0yeirNowhjRTxrRT6CXhGtyNAstYUTmT9G/znnqVojBeZZYA09PebjgoIcn6mhkbLy 5WLcmUbJ86I3FSXVxtQig/MsGLv/LxFA6XSnBlSJUM1TAqrr1cx2f+pwPUxduI/L3oe/ aWgEQ/S6JC7APB/NiFpJ+IBmb7OHFrxPP+tZkTR95+igDHIF+h1ySzOm4I1yL/hPv0Uo t6gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="bwzv6/E3"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id 11-20020a630f4b000000b003ab65457f62si14998987pgp.876.2022.05.02.18.02.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 18:02:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="bwzv6/E3"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 15A0156220; Mon, 2 May 2022 17:46:27 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379820AbiD2RwE (ORCPT + 99 others); Fri, 29 Apr 2022 13:52:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379817AbiD2Rv7 (ORCPT ); Fri, 29 Apr 2022 13:51:59 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EBC1D4C6F; Fri, 29 Apr 2022 10:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651254520; x=1682790520; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=5nf6dQ2n0VV5pIH0jfSN6QopQJy5UODqlRTGczslSjk=; b=bwzv6/E3Bb+l62kp1snAABw1w9xTYoLBL4TQnL5FnIA5udFG7HwbsZSb 9SDiHGaH31NJfBqKdJHVovi7tQSj2hgTvmyUowWaoEwCC4x0aW6FFtVaF nf3Fl2exD+hcvyIVXhSWguWPhJpmMirQy+a4a4mXcvrz9998f6C9MBfMQ +9hxdht1uDA9/BaVjzJLUdlgx6ptOJJT5Sb0QegcU0YXzZB5qP/Se9wpZ 4LwnlLRoiUK1hj/LrfudLSxKw2C5KZLYfM5peOknjes1H2XW/PXqdxhZz W5UdMoqJBh0L1j9HKGUhT+lNovcK4/v4WIRP1zQxcvTXZerd/yExySxyM g==; X-IronPort-AV: E=McAfee;i="6400,9594,10332"; a="266545761" X-IronPort-AV: E=Sophos;i="5.91,185,1647327600"; d="scan'208";a="266545761" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2022 10:46:40 -0700 X-IronPort-AV: E=Sophos;i="5.91,185,1647327600"; d="scan'208";a="582296660" Received: from jinggu-mobl1.amr.corp.intel.com (HELO [10.212.30.227]) ([10.212.30.227]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2022 10:46:39 -0700 Message-ID: Date: Fri, 29 Apr 2022 10:46:56 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v3 13/21] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Content-Language: en-US To: Sean Christopherson Cc: Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, pbonzini@redhat.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, sathyanarayanan.kuppuswamy@linux.intel.com, isaku.yamahata@intel.com References: <3664ab2a8e0b0fcbb4b048b5c3aa5a6e85f9618a.camel@intel.com> <5984b61f-6a4a-c12a-944d-f4a78bdefc3d@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.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 4/29/22 07:30, Sean Christopherson wrote: > On Fri, Apr 29, 2022, Dave Hansen wrote: ... >> A *good* way (although not foolproof) is to launch a TDX VM early >> in boot before memory gets fragmented or consumed. You might even >> want to recommend this in the documentation. > > What about providing a kernel param to tell the kernel to do the > allocation during boot? I think that's where we'll end up eventually. But, I also want to defer that discussion until after we have something merged. Right now, allocating the PAMTs precisely requires running the TDX module. Running the TDX module requires VMXON. VMXON is only done by KVM. KVM isn't necessarily there during boot. So, it's hard to do precisely today without a bunch of mucking with VMX. But, it would be really easy to do something less precise like: tdx_reserve_ratio=255 ... u8 *pamt_reserve[MAX_NR_NODES] for_each_online_node(n) { pamt_pages = (node_spanned_pages(n)/tdx_reserve_ratio) / PAGE_SIZE; pamt_reserve[n] = alloc_bootmem([pamt_pages); } Then have the TDX code use pamt_reserve[] instead of allocating more memory when it is needed later. That will work just fine as long as you know up front how much metadata TDX needs. If the metadata requirements change in an updated TDX module, the command-line will need to be updated to regain the guarantee. But, it can still fall back to the best-effort code that is in the series today. In other words, I think we want what is in the series today no matter what, and we'll want it forever. That's why it's the *one* way of doing things now. I entirely agree that there will be TDX users that want a stronger guarantee. You can arm-wrestle the distro folks who hate adding command-line tweaks when the time comes. ;)