From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id A7872941177 for ; Wed, 28 Feb 2024 05:33:46 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=2Ab64DoHlfZFTsQrUuK+203QdjjTU5Bl7fj+5hoFbL4=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1709098425; v=1; b=br14B9W8WUaQyd92pDWweXecIuYHGTLqWcD/nEDeGMI9+rmL5LNQ8EDeSoY9rqTNHQMukE/g WknovJNabWtQXKbvfJNcXSS/fJuvf2g+XaLvBbEzLycDZyccILLWyYlHvR0jMtD6qhZmMFNU4SF DAFZDCpcmJk4GVZpI5i4DsY0= X-Received: by 127.0.0.2 with SMTP id jP6zYY7687511xpGAoImkWWm; Tue, 27 Feb 2024 21:33:45 -0800 X-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.6959.1709098424591029674 for ; Tue, 27 Feb 2024 21:33:44 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-588-8b1oZfn_MgCLFXTWw4X0oQ-1; Wed, 28 Feb 2024 00:33:38 -0500 X-MC-Unique: 8b1oZfn_MgCLFXTWw4X0oQ-1 X-Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E93081021F65; Wed, 28 Feb 2024 05:33:37 +0000 (UTC) X-Received: from [10.39.192.46] (unknown [10.39.192.46]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 933C9492BC6; Wed, 28 Feb 2024 05:33:35 +0000 (UTC) Message-ID: <8163c5aa-47fd-330c-ba50-c24d676a5903@redhat.com> Date: Wed, 28 Feb 2024 06:33:34 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 06/10] OvmfPkg/ResetVector: add 5-level paging support To: devel@edk2.groups.io, kraxel@redhat.com Cc: Tom Lendacky , Jiewen Yao , Oliver Steffen , Erdem Aktas , Michael Roth , Ard Biesheuvel , Min Xu References: <20240222115435.85794-1-kraxel@redhat.com> <20240222115435.85794-7-kraxel@redhat.com> From: "Laszlo Ersek" In-Reply-To: <20240222115435.85794-7-kraxel@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: kLjrKjK3h6ORh2r4Xo1DlmQvx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=br14B9W8; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 2/22/24 12:54, Gerd Hoffmann wrote: > Add macros to check for 5-level paging and gigabyte page support. > Enable 5-level paging for the non-confidential-computing case. >=20 > Signed-off-by: Gerd Hoffmann > --- > OvmfPkg/ResetVector/ResetVector.inf | 1 + > OvmfPkg/ResetVector/Ia32/PageTables64.asm | 105 ++++++++++++++++++++++ > OvmfPkg/ResetVector/ResetVector.nasmb | 1 + > 3 files changed, 107 insertions(+) >=20 > diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/Re= setVector.inf > index a4154ca90c28..65f71b05a02e 100644 > --- a/OvmfPkg/ResetVector/ResetVector.inf > +++ b/OvmfPkg/ResetVector/ResetVector.inf > @@ -64,3 +64,4 @@ [FixedPcd] > gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize > + gEfiMdeModulePkgTokenSpaceGuid.PcdUse5LevelPageTable > diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/ResetVec= tor/Ia32/PageTables64.asm > index 84a7b4efc019..825589f31193 100644 > --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm > +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm > @@ -101,6 +101,97 @@ BITS 32 > loop .pageTableEntriesLoop4Level > %endmacro > =20 > +; > +; Check whenever 5-level paging can ca used (1) typo in comment > +; > +; Argument: jump label for 4-level paging > +; > +%macro Check5LevelPaging 1 > + ; check for cpuid leaf 0x07 > + mov eax, 0x00 > + cpuid > + cmp eax, 0x07 > + jb %1 > + > + ; check for la57 (aka 5-level paging) > + mov eax, 0x07 > + mov ecx, 0x00 > + cpuid > + bt ecx, 16 > + jnc %1 > + > + ; check for cpuid leaf 0x80000001 > + mov eax, 0x80000000 > + cpuid > + cmp eax, 0x80000001 > + jb %1 > + > + ; check for 1g pages > + mov eax, 0x80000001 > + cpuid > + bt edx, 26 > + jnc %1 > +%endmacro > + > +; > +; Create page tables for 5-level paging with gigabyte pages > +; > +; Argument: upper 32 bits of the page table entries > +; > +; We have 6 pages available for the early page tables, > +; we use four of them: > +; PT_ADDR(0) - level 5 directory > +; PT_ADDR(0x1000) - level 4 directory > +; PT_ADDR(0x2000) - level 2 directory (0 -> 1GB) > +; PT_ADDR(0x3000) - level 3 directory > +; > +; The level 2 directory for the first gigabyte has the same > +; physical address in both 4-level and 5-level paging mode, > +; SevClearPageEncMaskForGhcbPage depends on this. > +; > +; The 1 GB -> 4 GB range is mapped using 1G pages in the > +; level 3 directory. > +; > +%macro CreatePageTables5Level 1 > + ; level 5 > + mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDE_DIRECTORY_AT= TR > + mov dword[PT_ADDR (4)], %1 > + > + ; level 4 > + mov dword[PT_ADDR (0x1000)], PT_ADDR (0x3000) + PAGE_PDE_DIRECTO= RY_ATTR > + mov dword[PT_ADDR (0x1004)], %1 > + > + ; level 3 (1x -> level 2, 3x 1GB) > + mov dword[PT_ADDR (0x3000)], PT_ADDR (0x2000) + PAGE_PDE_DIRECTO= RY_ATTR > + mov dword[PT_ADDR (0x3004)], %1 > + mov dword[PT_ADDR (0x3008)], (1 << 30) + PAGE_PDE_LARGEPAGE_ATTR > + mov dword[PT_ADDR (0x300c)], %1 > + mov dword[PT_ADDR (0x3010)], (2 << 30) + PAGE_PDE_LARGEPAGE_ATTR > + mov dword[PT_ADDR (0x3014)], %1 > + mov dword[PT_ADDR (0x3018)], (3 << 30) + PAGE_PDE_LARGEPAGE_ATTR > + mov dword[PT_ADDR (0x301c)], %1 > + > + ; > + ; level 2 (512 * 2MB entries =3D> 1GB) > + ; > + mov ecx, 0x200 > +.pageTableEntriesLoop5Level: (2) suggest "..@pageTableEntriesLoop5Level" as label name > + mov eax, ecx > + dec eax > + shl eax, 21 > + add eax, PAGE_PDE_LARGEPAGE_ATTR > + mov dword[ecx * 8 + PT_ADDR (0x2000 - 8)], eax > + mov dword[(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], %1 > + loop .pageTableEntriesLoop5Level > +%endmacro > + > +%macro Enable5LevelPaging 0 > + ; set la57 bit in cr4 > + mov eax, cr4 > + bts eax, 12 > + mov cr4, eax > +%endmacro > + > ; > ; Modified: EAX, EBX, ECX, EDX > ; > @@ -125,6 +216,12 @@ SetCr3ForPageTables64: > ; normal (non-CoCo) workflow > ; > ClearOvmfPageTables > +%if PG_5_LEVEL > + Check5LevelPaging Paging4Level > + CreatePageTables5Level 0 > + jmp SetCr3La57 > +Paging4Level: > +%endif > CreatePageTables4Level 0 > jmp SetCr3 > =20 > @@ -151,6 +248,14 @@ TdxBspInit: > OneTimeCall TdxPostBuildPageTables > jmp SetCr3 > =20 > + ; > + ; common workflow > + ; > +%if PG_5_LEVEL > +SetCr3La57: > + Enable5LevelPaging > +%endif > + > SetCr3: > ; > ; Set CR3 now that the paging structures are available (3) I don't like SetCr3La57. It saves minimal code duplication, but makes the control flow much harder to follow. (3.1) From this patch, we have one (unconditional) jump to SetCr3La57. I suggest simply inlining that, like this: %if PG_5_LEVEL Check5LevelPaging Paging4Level CreatePageTables5Level 0 Enable5LevelPaging <-------- inline jmp SetCr3 <-------- here Paging4Level: %endif This adds one extra line before the unconditional jump, but removes 8 lines at the destination, *plus* it removes a quirky jump / reused code path. (3.2) From patch #8 ("OvmfPkg/ResetVector: wire up 5-level paging for TDX"), we have two jumps to SetCr3La57; one conditional and one unconditional. - The unconditional jump can be replaced with inlining (invoke the Enable5LevelPaging macro, then jump to SetCr3). - The conditional one can be reworked like this: %if PG_5_LEVEL cmp eax, TDX_AP_5_LEVEL jne CheckForSev Enable5LevelPaging jmp SetCr3 CheckForSev: %endif This way, the conditional jump is *local*; way easier to follow. The "CheckForSev" label much resembles the "Paging4Level" label above. The patch looks fine otherwise. Thanks! Laszlo > diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/= ResetVector.nasmb > index 366a70fb9992..2bd80149e58b 100644 > --- a/OvmfPkg/ResetVector/ResetVector.nasmb > +++ b/OvmfPkg/ResetVector/ResetVector.nasmb > @@ -53,6 +53,7 @@ > =20 > %define WORK_AREA_GUEST_TYPE (FixedPcdGet32 (PcdOvmfWorkAreaBas= e)) > %define PT_ADDR(Offset) (FixedPcdGet32 (PcdOvmfSecPageTabl= esBase) + (Offset)) > +%define PG_5_LEVEL (FixedPcdGetBool (PcdUse5LevelPage= Table)) > =20 > %define GHCB_PT_ADDR (FixedPcdGet32 (PcdOvmfSecGhcbPage= TableBase)) > %define GHCB_BASE (FixedPcdGet32 (PcdOvmfSecGhcbBase= )) -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116085): https://edk2.groups.io/g/devel/message/116085 Mute This Topic: https://groups.io/mt/104506793/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-