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 AEA6174003B for ; Mon, 29 Jan 2024 21:13:09 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=RS3WMTn/PJj+KIR9/SO/P6wxbFs6mpk7gKYMcyyztjE=; 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=1706562788; v=1; b=H3S2WLXfvsqowcWqF53UXjZgneZPt5GpEYkUWVlTjm8JNA52LIC7eZE/4qEvDINE18xOJZ4d jUylNEYle+EfvejDbEaWwp7A4rtT0fVbLr6/ykgNnykLuCYtErkpqjgRoYzxvchNuW4yagsZgb+ PEiywMXHC9r6fLGrFwxOez80= X-Received: by 127.0.0.2 with SMTP id roOQYY7687511xKYsrfGKeUY; Mon, 29 Jan 2024 13:13:08 -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.web10.2523.1706562787592332616 for ; Mon, 29 Jan 2024 13:13:07 -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-9-fgNfsbsAOmSA0kJv9rJYaQ-1; Mon, 29 Jan 2024 16:13:01 -0500 X-MC-Unique: fgNfsbsAOmSA0kJv9rJYaQ-1 X-Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (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 D59703C29A74; Mon, 29 Jan 2024 21:13:00 +0000 (UTC) X-Received: from [10.39.192.97] (unknown [10.39.192.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5EA6E1121313; Mon, 29 Jan 2024 21:12:59 +0000 (UTC) Message-ID: <290291cc-fc01-fd5d-f12d-eced42e378ca@redhat.com> Date: Mon, 29 Jan 2024 22:12:58 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/PlatformInitLib: add 5-level paging support To: devel@edk2.groups.io, kraxel@redhat.com Cc: Oliver Steffen , Ard Biesheuvel , Michael Roth , Min Xu , Tom Lendacky , Erdem Aktas , Jiewen Yao , Liming Gao References: <20240129120201.344234-1-kraxel@redhat.com> <20240129120201.344234-4-kraxel@redhat.com> From: "Laszlo Ersek" In-Reply-To: <20240129120201.344234-4-kraxel@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 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: ISvtD22S3Ib58X3cmOJV5DTix7686176AA= 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=H3S2WLXf; 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 1/29/24 13:02, Gerd Hoffmann wrote: > Adjust physical address space logic for la57 mode (5-level paging). > With a larger logical address space we can identity-map a larger > physical address space. >=20 > Signed-off-by: Gerd Hoffmann > --- > OvmfPkg/Library/PlatformInitLib/MemDetect.c | 57 ++++++++++++++------- > 1 file changed, 38 insertions(+), 19 deletions(-) >=20 > diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Librar= y/PlatformInitLib/MemDetect.c > index f042517bb64a..b882d9b82fa8 100644 > --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c > +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c > @@ -628,11 +628,12 @@ PlatformAddressWidthFromCpuid ( > IN BOOLEAN QemuQuirk > ) > { > - UINT32 RegEax, RegEbx, RegEcx, RegEdx, Max; > - UINT8 PhysBits; > - CHAR8 Signature[13]; > - BOOLEAN Valid =3D FALSE; > - BOOLEAN Page1GSupport =3D FALSE; > + UINT32 RegEax, RegEbx, RegEcx, RegEdx, Max; > + UINT8 PhysBits; > + CHAR8 Signature[13]; > + IA32_CR4 Cr4; > + BOOLEAN Valid =3D FALSE; > + BOOLEAN Page1GSupport =3D FALSE; Initialization of locals breaks the edk2 coding conventions. ... Well, I now realize this is preexistent code, only shown as "different" due to visual realignment. Ignore. > =20 > ZeroMem (Signature, sizeof (Signature)); > =20 > @@ -670,30 +671,48 @@ PlatformAddressWidthFromCpuid ( > } > } > =20 > + Cr4.UintN =3D AsmReadCr4 (); > + > DEBUG (( > DEBUG_INFO, > - "%a: Signature: '%a', PhysBits: %d, QemuQuirk: %a, Valid: %a\n", > + "%a: Signature: '%a', PhysBits: %d, QemuQuirk: %a, la57: %a, Valid: = %a\n", > __func__, > Signature, > PhysBits, > QemuQuirk ? "On" : "Off", > + Cr4.Bits.LA57 ? "On" : "Off", > Valid ? "Yes" : "No" > )); > =20 > if (Valid) { > - if (PhysBits > 46) { > - /* > - * Avoid 5-level paging altogether for now, which limits > - * PhysBits to 48. Also avoid using address bit 48, due to sign > - * extension we can't identity-map these addresses (and lots of > - * places in edk2 assume we have everything identity-mapped). > - * So the actual limit is 47. > - * > - * Also some older linux kernels apparently have problems handling > - * phys-bits > 46 correctly, so use that as limit. > - */ > - DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 46 (avoid 5-level pagin= g)\n", __func__)); > - PhysBits =3D 46; > + /* > + * Due to the sign extension we can use only the lower half of the > + * virtual address space to identity-map physical address space, > + * which gives us a 47 bit wide address space with 4 paging levels > + * and a 56 bit wide address space with 5 paging levels. > + */ > + if (Cr4.Bits.LA57) { > + if (PhysBits > 48) { > + /* > + * Some Intel CPUs support 5-level paging, have more than 48 > + * phys-bits but support only 4-level EPT, which effectively > + * limits guest phys-bits to 48. Until we have some way to > + * communicate that limitation from hypervisor to guest limit (1) Very nice comment, but please insert a comma "," between the words "guest" and "limit". > + * phys-bits to 48 unconditionally. > + */ > + DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 48 (5-level paging)\n= ", __func__)); > + PhysBits =3D 48; > + } > + } else { > + if (PhysBits > 46) { > + /* > + * Some older linux kernels apparently have problems handling > + * phys-bits > 46 correctly, so use that instead of 47 as > + * limit. > + */ > + DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 46 (4-level paging)\n= ", __func__)); > + PhysBits =3D 46; > + } > } > =20 > if (!Page1GSupport && (PhysBits > 40)) { Reviewed-by: Laszlo Ersek -=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 (#114747): https://edk2.groups.io/g/devel/message/114747 Mute This Topic: https://groups.io/mt/104029638/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-