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.129.124]) by mx.groups.io with SMTP id smtpd.web11.64353.1638864287589593970 for ; Tue, 07 Dec 2021 00:04:48 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iKn/marU; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638864286; 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=CTEJFNBk03F2PI/zuZOIsz2Z08EiwRoJRNRS2w2QeKY=; b=iKn/marU98VWqDpIrZX9ple2pN3zCOE5mQVRbZPMgMrUmcwGx+h5Hpcx3dTv+zOKXHncZj HgjeAH3VYAVw5JpO1SOAARSgKHHoiJ1rRdTUiKslxtxy1IyS1+DM42FfuzjcRCMESjbIxk XiBfaDEUsx5PVSB0dg/x5XOwnFTS8Ag= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-591-PT2ihz-iMNSryF8sN7n_yw-1; Tue, 07 Dec 2021 03:04:44 -0500 X-MC-Unique: PT2ihz-iMNSryF8sN7n_yw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CC1A0801B0F; Tue, 7 Dec 2021 08:04:42 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6481660843; Tue, 7 Dec 2021 08:04:42 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 6527718003A1; Tue, 7 Dec 2021 09:04:40 +0100 (CET) Date: Tue, 7 Dec 2021 09:04:40 +0100 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , "jejb@linux.ibm.com" , "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Message-ID: <20211207080440.pgbd73f2jx2z2id3@sirius.home.kraxel.org> References: <5d39c546fe66fc945e9687f187ed9892b6a6a00c.camel@linux.ibm.com> <20211125083219.uiqbg7fsoervmdkq@sirius.home.kraxel.org> <20211201135506.bwxpo5h4fr5lcbni@sirius.home.kraxel.org> <20211206145737.e3bh6fl65j6qw62f@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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 Hi, > [Jiewen] OK, I talked with Min again. 12ms is not right data today. > We have bigger number, but I cannot share the data according to legal reason. > > But I agree with your statement that, if the data is small enough, then we don't need MP in sec. > > I propose this way: > 1) In first patch, we drop MP in SEC. Yes. Next implement lazy accept ... > 2) We can revisit if it is really needed later, when the TDX platform is about to launch. ... then revisit where we stand in terms of boot performance. And, yes, doing that on the final tdx platform hardware instead of preliminary development hardware makes sense too. > > Where does the 50% increase for GPAW=52 comes from? > > [Jiewen] Yes, this is about page table. > The reason is that UEFI spec requires you to map all memory. You have to create page table for all. Seems that has changed with the latest (2.9) revision of the specs which explicitly excludes unaccepted memory. From section 2.3.4: Paging mode is enabled and any memory space defined by the UEFI memory map is identity mapped (virtual address equals physical address), although the attributes of certain regions may not have all read, write, and execute attributes or be unmarked for purposes of platform protection. The mappings to other regions, such as those for unaccepted memory, are undefined and may vary from implementation to implementation. So implementing lazy accept should bring the initial memory footprint down because page tables for unaccepted memory are not needed in SEC/PEI. We can lazily allocate them in DXE instead when accepting memory (either all memory, or just enough to load the linux kernel and have linux accept the remaining memory). take care, Gerd