From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.6094.1634194272889690211 for ; Wed, 13 Oct 2021 23:51:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NINxCu3b; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634194272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bbnMO7KnJ/NBGKQdTeqg0bLmOikndXHsSG9Ul6BTKA4=; b=NINxCu3bU02dSpBcPful1r7R9qUdVzg6DhclAtOabKeyGSYSnA7oWSHYjVx0quHtS0Mws/ 0D7Pqi+fgpcbbAMvvjj6G9xceOWVng/eMIOpcP2k4DhkQtkWo3B9AwGG9kXi63tEb/4eRu 1nXoRV2Jk/aTH/1sSa4qthGNxsy9ttI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-382-BT2ETFFgOEaqP-AVIg-Hcw-1; Thu, 14 Oct 2021 02:51:06 -0400 X-MC-Unique: BT2ETFFgOEaqP-AVIg-Hcw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4E7D28042A5; Thu, 14 Oct 2021 06:51:05 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A4EFB60657; Thu, 14 Oct 2021 06:51:04 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8798B18007AC; Thu, 14 Oct 2021 08:51:02 +0200 (CEST) Date: Thu, 14 Oct 2021 08:51:02 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V2 14/28] OvmfPkg: Update SecEntry.nasm to support Tdx Message-ID: <20211014065102.6m4uzcq5fv3g7h3h@sirius.home.kraxel.org> References: <2f440070a868156b6f22ab57076f86bad003c88e.1633401643.git.min.m.xu@intel.com> <20211012103851.bfqbrbmhhsmtlozx@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 14, 2021 at 12:55:22AM +0000, Xu, Min M wrote: > On October 12, 2021 6:39 PM, Gerd Hoffmann wrote: > > Hi, > > > > > - AcceptPages: > > > To mitigate the performance impact of accepting pages in SEC phase on > > > BSP, BSP will parse memory resources and assign each AP the task of > > > accepting a subset of pages. This command may be called several times > > > until all memory resources are processed. In accepting pages, PageLevel > > > may fall back to smaller one if SIZE_MISMATCH error is returned. > > > > Hmm, I'm wondering whenever it is useful to have this in the first place with > > the longer-term plan to implement lazy on-demand acceptance. > To mitigate the performance impact of accepting pages, there are 3 ways. > 1. Big accept page size. > 2. Accept the pages by BSP and APs together. > 3. Lazy on-demand acceptance. > From the perspective of implementation complexity, 1 < 2 < 3. > Lazy on-demand acceptance need the update not only in TDVF, but also > in Guest kernel. More investigation shows it also impacts the grub and > memory management in EDK2. Yes. > From the perspective of performance improvement, 2M accept page size + > BSP/AP together, can improve the performance a lot. Yes. The question is whenever that has to happen in the SEC phase though, especially considering that we want get rid of that longer-term with the switch to lazy acceptance. You have patches to setup MpLib for Tdx. So it should be possible to use MpLib to distribute the acceptance jobs to the APs in PEI or DXE phase instead. Advantages: * You don't need large chunks of assembler code for the APs to handle acceptance. * The AP boot can be simplified, you can just let them spin until the BSP initialized MpLib. * You can continue to use the MpLib-based parallel acceptance code when switching over to lazy on-demand acceptance later on. The BSP would still need to accept some memory in SEC (enough to reach PEI or DXE), but that shouldn't be very much. take care, Gerd