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 BF8197803D8 for ; Thu, 1 Feb 2024 23:32:08 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=KnlZtv005R8Eorqf3fjRuYGT3OnOXn65IIO6e4pfu4o=; 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=1706830327; v=1; b=a3gjNuMQDeoLB8fyzDxcJZSu7QOcT9ta56RlFWNPesPHbPkwmTYUXdQs7mesG5dqgxTD2f/L Y1McXfX1T643tyE7NNsVEH7OhW3aCPCG2fAsBKNV5/V3ZR6d62rKDVEjUaClBLHhtsrr8bF+5lq rSlqy3r05pClTIyJq5gu68e4= X-Received: by 127.0.0.2 with SMTP id 8Kp9YY7687511xpN6GV77Wmu; Thu, 01 Feb 2024 15:32:07 -0800 X-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.10701.1706830326304632613 for ; Thu, 01 Feb 2024 15:32:06 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-503-k2UpWwntPQ65bkD4zSbbFg-1; Thu, 01 Feb 2024 18:32:01 -0500 X-MC-Unique: k2UpWwntPQ65bkD4zSbbFg-1 X-Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 AB6133C0BE47; Thu, 1 Feb 2024 23:32:00 +0000 (UTC) X-Received: from [10.39.192.71] (unknown [10.39.192.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 32EEA1C060AF; Thu, 1 Feb 2024 23:31:58 +0000 (UTC) Message-ID: <9b289ce3-bfe4-2654-7669-7cf04692fe2a@redhat.com> Date: Fri, 2 Feb 2024 00:31:53 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v2 4/5] OvmfPkg/ResetVector: add 5-level paging support To: devel@edk2.groups.io, thomas.lendacky@amd.com, Gerd Hoffmann Cc: Erdem Aktas , Oliver Steffen , Jiewen Yao , Ard Biesheuvel , Min Xu , Michael Roth , Liming Gao References: <20240130123204.764453-1-kraxel@redhat.com> <20240130123204.764453-5-kraxel@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 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: iTTacJA1WdKJESZXWwB5N8OGx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=a3gjNuMQ; 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/1/24 16:44, Lendacky, Thomas via groups.io wrote: > On 1/30/24 06:32, Gerd Hoffmann wrote: >> Compile the OVMF ResetVector with 5-level paging support in case >> PcdUse5LevelPageTable is TRUE. >> >> When enabled the ResetVector will check at runtime whenever support for >> 5-level paging and gigabyte pages is available.  In case both features >> are supported it will run OVMF in 5-level paging mode, otherwise >> fallback to 4-level paging. >> >> Gigabyte pages are required to make sure we can fit the page tables into >> the available space.  We have six pages available, with gigabyte pages >> we need three of them, with 2M pages we would need seven. >> >> Signed-off-by: Gerd Hoffmann >> --- >>   OvmfPkg/ResetVector/ResetVector.inf       |  1 + >>   OvmfPkg/ResetVector/Ia32/PageTables64.asm | 77 +++++++++++++++++++++++ >>   OvmfPkg/ResetVector/ResetVector.nasmb     |  1 + >>   3 files changed, 79 insertions(+) >> >> diff --git a/OvmfPkg/ResetVector/ResetVector.inf >> b/OvmfPkg/ResetVector/ResetVector.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/ResetVector/Ia32/PageTables64.asm >> index 6fec6f2beeea..cf64c88b6cda 100644 >> --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm >> +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm >> @@ -86,6 +86,82 @@ clearPageTablesMemoryLoop: >>       mov     dword[ecx * 4 + PT_ADDR (0) - 4], eax >>       loop    clearPageTablesMemoryLoop >>   +%if PG_5_LEVEL >> + >> +    ; save GetSevCBitMaskAbove31 result (cpuid changes edx) >> +    mov     edi, edx >> + >> +    ; check for cpuid leaf 0x07 >> +    mov     eax, 0x00 >> +    cpuid > > Because of these CPUID instructions, this won't work for SEV-ES / > SEV-SNP. To use these we'll need to have a (special 32-bit) #VC handler > in place. Currently that is done in only in > OvmfPkg/ResetVector/Ia32/AmdSev.asm for the CheckSevFeatures function, > where the #VC handler is established at the beginning of the function, > but it is removed when leaving the function. > > The SEV support in general needs looking into in order to support > 5-level paging. At the time the SEV support was developed, there wasn't > a page table library and so there is some 4-level page table > manipulation support in the BaseMemEncryptSevLib that really needs to be > converted to use the page table library. > > I don't have an objection to the series, as long as > PcdUse5LevelPageTable is not set to TRUE by default for the Ovmf packages. Well, I do have a slight objection: > >> +    cmp     eax, 0x07 >> +    jb      Paging4Lvl >> + >> +    ; check for la57 (aka 5-level paging) >> +    mov     eax, 0x07 >> +    mov     ecx, 0x00 >> +    cpuid >> +    bt      ecx, 16 >> +    jnc     Paging4Lvl >> + >> +    ; check for cpuid leaf 0x80000001 >> +    mov     eax, 0x80000000 >> +    cpuid >> +    cmp     eax, 0x80000001 >> +    jb      Paging4Lvl >> + >> +    ; check for 1g pages >> +    mov     eax, 0x80000001 >> +    cpuid >> +    bt      edx, 26 >> +    jnc     Paging4Lvl >> + >> +    ; >> +    ; Use 5-level paging with gigabyte pages. >> +    ; >> +    ; We have 6 pages available for the early page tables, >> +    ; due to the use of gigabyte pages we need three pages >> +    ; and everything fits in. >> +    ; >> +    debugShowPostCode 0x51      ; 5-level paging >> + >> +    ; restore GetSevCBitMaskAbove31 result >> +    mov     edx, edi >> + >> +    ; level 5 >> +    mov     dword[PT_ADDR (0)], PT_ADDR (0x1000) + >> PAGE_PDE_DIRECTORY_ATTR >> +    mov     dword[PT_ADDR (4)], edx >> + >> +    ; level 4 >> +    mov     dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + >> PAGE_PDE_DIRECTORY_ATTR >> +    mov     dword[PT_ADDR (0x1004)], edx >> + >> +    ; level 3 (four 1GB pages for the lowest 4G) >> +    mov     dword[PT_ADDR (0x2000)], (0 << 30) + PAGE_PDE_LARGEPAGE_ATTR >> +    mov     dword[PT_ADDR (0x2004)], edx >> +    mov     dword[PT_ADDR (0x2008)], (1 << 30) + PAGE_PDE_LARGEPAGE_ATTR >> +    mov     dword[PT_ADDR (0x200c)], edx >> +    mov     dword[PT_ADDR (0x2010)], (2 << 30) + PAGE_PDE_LARGEPAGE_ATTR >> +    mov     dword[PT_ADDR (0x2014)], edx >> +    mov     dword[PT_ADDR (0x2018)], (3 << 30) + PAGE_PDE_LARGEPAGE_ATTR >> +    mov     dword[PT_ADDR (0x201c)], edx >> + >> +    ; set la57 bit in cr4 >> +    mov     eax, cr4 >> +    bts     eax, 12 >> +    mov     cr4, eax >> + >> +    ; done >> +    jmp     PageTablesReady Note this jump here... >> + >> +Paging4Lvl: >> +    debugShowPostCode 0x41      ; 4-level paging >> + >> +    ; restore GetSevCBitMaskAbove31 result >> +    mov     edx, edi >> + >> +%endif ; PG_5_LEVEL >> + >>       ; >>       ; Top level Page Directory Pointers (1 * 512GB entry) >>       ; >> @@ -117,6 +193,7 @@ pageTableEntriesLoop: >>       mov     [(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], edx >>       loop    pageTableEntriesLoop >>   +PageTablesReady: >>       ; Clear the C-bit from the GHCB page if the SEV-ES is enabled. >>       OneTimeCall   SevClearPageEncMaskForGhcbPage Landing here. I requested this; see point (4) at . But knowing (now!) that the neighborhood (= the 5 level paging setup) isn't compatible with / reachable under SEV-ES in the first place, this jump only seems wishful thinking. The best I could propose: jump again to SetCr3 (like in v1), but add a comment that it's not a mistake, but intentional (because the stuff doesn't work on SEV-ES anyway). Thanks Laszlo >>   diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb >> b/OvmfPkg/ResetVector/ResetVector.nasmb >> index 5832aaa8abf7..16b3eee57671 100644 >> --- a/OvmfPkg/ResetVector/ResetVector.nasmb >> +++ b/OvmfPkg/ResetVector/ResetVector.nasmb >> @@ -49,6 +49,7 @@ >>     %define WORK_AREA_GUEST_TYPE          (FixedPcdGet32 >> (PcdOvmfWorkAreaBase)) >>   %define PT_ADDR(Offset)               (FixedPcdGet32 >> (PcdOvmfSecPageTablesBase) + (Offset)) >> +%define PG_5_LEVEL                    (FixedPcdGetBool >> (PcdUse5LevelPageTable)) >>     %define GHCB_PT_ADDR                  (FixedPcdGet32 >> (PcdOvmfSecGhcbPageTableBase)) >>   %define GHCB_BASE                     (FixedPcdGet32 >> (PcdOvmfSecGhcbBase)) > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114982): https://edk2.groups.io/g/devel/message/114982 Mute This Topic: https://groups.io/mt/104052208/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-