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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1B5CC43214 for ; Tue, 10 Aug 2021 18:05:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9236C604D7 for ; Tue, 10 Aug 2021 18:05:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239204AbhHJSFA (ORCPT ); Tue, 10 Aug 2021 14:05:00 -0400 Received: from mga04.intel.com ([192.55.52.120]:65508 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235141AbhHJSA7 (ORCPT ); Tue, 10 Aug 2021 14:00:59 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10072"; a="213102075" X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="213102075" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2021 10:52:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="570864967" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga004.jf.intel.com with ESMTP; 10 Aug 2021 10:52:01 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 833FBF9; Tue, 10 Aug 2021 20:51:44 +0300 (EEST) Date: Tue, 10 Aug 2021 20:51:44 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] x86: Impplement support for unaccepted memory Message-ID: <20210810175144.uqlddcicyrweqb4j@black.fi.intel.com> References: <20210810062626.1012-1-kirill.shutemov@linux.intel.com> <4b80289a-07a4-bf92-9946-b0a8afb27326@intel.com> <20210810151548.4exag5uj73bummsr@black.fi.intel.com> <82b8836f-a467-e5ff-08f3-704a85b9faa0@intel.com> <20210810173124.vzxpluaepdfe5aum@black.fi.intel.com> <51d9168c-ac14-0907-79b3-5d4dd46f92d6@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51d9168c-ac14-0907-79b3-5d4dd46f92d6@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 10, 2021 at 10:36:21AM -0700, Dave Hansen wrote: > > The difference is going to be substantially lower once we get it optimized > > properly. > > What does this mean? Is this future work in the kernel or somewhere in > the TDX hardware/firmware which will speed things up? Kernel has to be changed to accept memory in 2M and 1G chunks where possible. The interface exists and described in spec, but not yet used in guest kernel. It would cut hypercall overhead dramatically. It makes upfront memory accept more bearable and lowers latency of lazy memory accept. So I expect the gap being not 20x, but like 3-5x (which is still huge). -- Kirill A. Shutemov