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.web12.645.1630647567796744221 for ; Thu, 02 Sep 2021 22:39:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SIrK/c01; 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=1630647567; 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=maIWHGTW3FmO+BQU6Trnay1x0WuCFUgwqK8KglNqwUc=; b=SIrK/c01/HDphcES0CN3GHLZv8orIHsMT/kBUJ/C7j2frwG0M4FI8aW1rqf65TFpvsJDK7 9dqunMOO7UDnXUU/P68n5g3QdmTx7b0EO+LVzRNmAW91cpZ77K4B0CXTC75Ne7A6KP151R IDmL5RdJ2HSu5ef9+r5QYw79CTF/S7k= 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-356-Pja770kPO9iUgpDgZ6sX3w-1; Fri, 03 Sep 2021 01:39:23 -0400 X-MC-Unique: Pja770kPO9iUgpDgZ6sX3w-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 4B966802923; Fri, 3 Sep 2021 05:39:22 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E0AEF69CBB; Fri, 3 Sep 2021 05:39:21 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id EA09C18000A3; Fri, 3 Sep 2021 07:39:19 +0200 (CEST) Date: Fri, 3 Sep 2021 07:39:19 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "Xu, Min M" , "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V5 2/2] OvmfPkg/ResetVector: Enable Intel TDX in ResetVector of Ovmf Message-ID: <20210903053919.ybkq7imveuxbufao@sirius.home.kraxel.org> References: <81c97a782bbbf83043854ad8a86d14604918d788.1630289827.git.min.m.xu@intel.com> <20210830074058.22gfqmzrha4su6fh@sirius.home.kraxel.org> <20210831053510.ian6sqpefzmrrfi7@sirius.home.kraxel.org> <20210902071812.2qet62x7npu25rht@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 Fri, Sep 03, 2021 at 03:03:50AM +0000, Yao, Jiewen wrote: > HI Min/Gerd > I think we have multiple ways to enable 5 level paging. > > 1) We do not change to 5 level in initial paging in reset vector. > We can switch from 4 level to 5 level later when permanent memory is available. > We don't need change flash layout. Does that work with tdx? I had the impression that ovmf can't choose whenever it uses 4-level or 5-level paging in case tdx is enabled, but instead has to use what the tdx firmware (or hardware?) dictates. And this being the reason why we have to deal with that in the reset vector in the first place. But maybe I'm wrong here. If we can use 4-level paging initially, then we surely should go for option (1) and simply not touch the reset vectors paging code. > 2) We can enable 5 level paging in initial paging. > 2.1) We can enable 5 level paging with 1G paging support. > We don't need change flash layout. Only 3 pages is needed. (12K) > I don't know if we can real case that a CPU support 5 level but without 1G paging. > > 2.2) We can still enable 5 level paging with 2M paging. > 2.2.1) We can change flash layout to increase 6 pages (24K) memory to 7 pages (28K). > So the CR3 in 5 level is same as the CR3 in 4 level. > > 2.2.2) We don't change flash layout but steal another page in somewhere else - PcdOvmfPml5Base > That means CR3 in 5 level is different with CR4 in 4 level. > Personally, I don't like the idea to create PcdOvmfPml5Base/Size > Other AP MUST check 5 level and 4 level to get right CR3 location. That is tricky and unnecessary. > > In current patch, 2.2.2) is used. > > I suggest we also evaluate option 1), 2.1) and 2.2.1). My idea is 2.2.1 with a fixed, 5-level layout. Then use 4-level-cr3 == 5-level-cr3 + PAGE_SIZE 2.1 looks good too. take care, Gerd