From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.apple.com [17.179.253.48]) by mx.groups.io with SMTP id smtpd.web08.2017.1668024880994321665 for ; Wed, 09 Nov 2022 12:14:41 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=wYVR6fYE; spf=pass (domain: apple.com, ip: 17.179.253.48, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2A9KBgsW016713; Wed, 9 Nov 2022 12:14:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=FjEWiejrgGqfLoaKTF8lw6+WSScsNxtAYF2o6ugYp5M=; b=wYVR6fYEhKWheQqd0RDtwcTqLAun1KfBsDIaeIqbgcjklgIJrhDcbcLa6eSVwL7O70Np /wYxRnARk0dLqXJC0wv83m3vcAPoT3z79C5+p+vdIrryyTJ6hJ1Is0GAP8MYvUwaQ96t QCU40h2GRs9e3/UswNbRYJAjpUDv0xI9flW6zDiM2y8SNDAuHgXaUloYXAbXYrkReIxO EUJFRGI3xVBIyMcv1gbY6m96R5Xirxzwlm3qT9EXcpONGFNkCHl4uPhVa8QGmyAm7i+3 kp84ezuUX+b7NFZrtaKYIJonI4S4lG8QZ4wwwhc5yWTpEOUmlXQ4eJhoF06AzHj7BOjc Ow== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3kr2tu1fhr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 09 Nov 2022 12:14:36 -0800 Received: from rn-mailsvcp-policy-lapp01.rno.apple.com (rn-mailsvcp-policy-lapp01.rno.apple.com [17.179.253.18]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPS id <0RL3002PHK8CCJK0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 09 Nov 2022 12:14:36 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-policy-lapp01.rno.apple.com by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) id <0RL300100K6IHZ00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Wed, 09 Nov 2022 12:14:36 -0800 (PST) X-Va-A: X-Va-T-CD: f3775ddbc0d6ec6e84cae35106ea80f4 X-Va-E-CD: 1e7976e2ce498a65948d3f8432b4c139 X-Va-R-CD: 056252d7f8421721eda401b5919891c9 X-Va-CD: 0 X-Va-ID: 45dca57a-030f-45b8-b587-e188ed033e8d X-V-A: X-V-T-CD: f3775ddbc0d6ec6e84cae35106ea80f4 X-V-E-CD: 1e7976e2ce498a65948d3f8432b4c139 X-V-R-CD: 056252d7f8421721eda401b5919891c9 X-V-CD: 0 X-V-ID: 413cc2f8-bb18-4be6-81aa-f3ab570c59ed X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545,18.0.895 definitions=2022-11-09_06:2022-11-09,2022-11-09 signatures=0 Received: from smtpclient.apple (unknown [17.11.229.200]) by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPSA id <0RL300508K8B6H00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Wed, 09 Nov 2022 12:14:36 -0800 (PST) From: "Andrew Fish" Message-id: <229C72F3-0994-425F-8D89-B3CB3ACCA8CE@apple.com> MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.200.22\)) Subject: Re: [edk2-devel] Access 64bit address space in 32bit mode Date: Wed, 09 Nov 2022 12:14:25 -0800 In-reply-to: Cc: yoshinoyatoko@163.com To: devel@edk2.groups.io, Vincent Zimmer References: <153cddfb.10e9.183a7eb0792.Coremail.yoshinoyatoko@163.com> <74daa6ed.1623.184553d61a8.Coremail.yoshinoyatoko@163.com> X-Mailer: Apple Mail (2.3731.200.22) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545,18.0.895 definitions=2022-11-09_06:2022-11-09,2022-11-09 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_BAA2F219-5CE0-4550-934E-69E8288CE212" --Apple-Mail=_BAA2F219-5CE0-4550-934E-69E8288CE212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Vincent, Thanks! I=E2=80=99d forgotten about that path.=20 The other answer is defer the work to a DXE driver that runs 64-bit x86. Thanks, Andrew Fish > On Nov 9, 2022, at 10:58 AM, vincent zimmer wr= ote: >=20 > we have the challenge of 32-bit PEI needing to access 64-bit addresses to= support 64-bit DXE/UEFI OS's in the capsule use-case scenario. This is de= scribed in https://raw.githubusercontent.com/tianocore-docs/Docs/master/Whi= te_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf page= 22 with code https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Un= iversal/CapsulePei >=20 > On Wed, Nov 9, 2022 at 9:21 AM Andrew Fish via groups.io > wrote: >>=20 >>> On Nov 7, 2022, at 7:16 PM, Yoshinoya > wrote: >>>=20 >>> Hello >>> Is it possible to access 64bit address space in 32bit mode? >>>=20 >>=20 >> I assume you are talking about x86? >>=20 >>=20 >>> For example, opcode prefix 0x66/67 could let code running in 16bit mode= to access 32bit data/address. >>>=20 >>=20 >> This is more complex than just instruction prefix. You need the CPU to b= e setup in big real mode via the GDT, so you basically have a 32-bit enviro= nment setup via GDT etc. Also the prefix opcodes have different meaning in = different modes. I don=E2=80=99t think there is a way to make 32-bit code a= ccess 64-bit data via instruction prefix even if a 64-bit GDT was setup wit= h paging enabled. =20 >>=20 >>> Or, establishing page table is a must requirement for accessing 64bit a= ddress space. >>>=20 >>=20 >> For x86 you have to have 64-bit versions of the IDT, GDT, and you need t= o enable paging to enter 64-bit Long Mode.=20 >>=20 >> In a 32-bit x86 world you can access up to 64 GB of physical memory via = using 32-bit page table using PAE [1]. PAE is a 32-bit virtual address spac= e, but with support for a 36-bit physical address. I think in the olden day= s of 32-bit x86 EFI servers would have custom EFI code that enabled paging = in 32-bit and carved out a chunk of the 32-bit memory space that could be m= apped to 36-bit physical addresses. I think this was platform specific code= and I don=E2=80=99t know of any open source version. The 32-bit Long Mode = EFI does not have paging enabled, so adding PAE means enabling paging yours= elf.=20 >>=20 >> The edk2 has the opposite version of this code so you can call 16-bit re= ally mode (Legacy BIOS) from 32-bit Protected mode, or 64-bit Long Mode. Th= is is the code to Thunk for 32-bit/64-bit mode to 16-bit code [2]/=20 >>=20 >> [1] https://en.wikipedia.org/wiki/Physical_Address_Extensio n >> [2] https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib= /X86Thunk.c >> >> edk2/Thunk16.nasm at master =C2=B7 tianocore/edk2 >> github.com >> edk2/Thunk16.nasm at master =C2=B7 tianocore/edk2 >> github.com >>=20 >> edk2/Thunk16.nasm at master =C2=B7 tianocore/edk2 >> github.com >> edk2/Thunk16.nasm at master =C2=B7 tianocore/edk2 >> github.com >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>=20 >>> Thanks >>> =20 >>=20 >>=20 >>=20 >=20 >=20 > --Apple-Mail=_BAA2F219-5CE0-4550-934E-69E8288CE212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Vincent,

Thank= s! I=E2=80=99d forgotten about that path. 

Th= e other answer is defer the work to a DXE driver that runs 64-bit x86.

Thanks,

Andrew Fish
<= br>
On Nov 9, 2022, at 10:58 AM, vincent zimm= er <vincent.zimmer@gmail.com> wrote:

we have the challenge of 32-bit PEI needing to access 64-bit addresses= to support 64-bit DXE/UEFI OS's in the capsule use-case scenario.  Th= is is described in https://r= aw.githubusercontent.com/tianocore-docs/Docs/master/White_Papers/A_Tour_Bey= ond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf page 22 with code https://github.com/tianocore/edk2/t= ree/master/MdeModulePkg/Universal/CapsulePei

On Wed, Nov 9, 2022 at 9:21 AM Andrew Fish via group= s.io <afish=3Dapple.com@groups.io> wrote:

On Nov 7, 2022, at 7:16 PM, Yoshinoya <yoshinoyatoko@163.com> = wrote:

Hello
Is it possible to access 64bit address space in 32bit mode?


I assume you are talking about x86?


For example, opcode prefix 0x6= 6/67 could let code running in 16bit mode to access 32bit data/address.


<= /div>
This is more complex than just instruction prefix. You need the C= PU to be setup in big real mode via the GDT, so you basically have a 32-bit= environment setup via GDT etc. Also the prefix opcodes have different mean= ing in different modes. I don=E2=80=99t think there is a way to make 32-bit= code access 64-bit data via instruction prefix even if a 64-bit GDT was se= tup with paging enabled.  

Or, establishing page table is a must requirement for a= ccessing 64bit address space.


For x86 you have to have 64= -bit versions of the IDT, GDT, and you need to enable paging to enter 64-bi= t Long Mode. 

In a 32-bit x86 world you can a= ccess up to 64 GB of physical memory via using 32-bit page table using PAE = [1]. PAE is a 32-bit virtual address space, but with support for a 36-bit p= hysical address. I think in the olden days of 32-bit x86 EFI servers would = have custom EFI code that enabled paging in 32-bit and carved out a chunk o= f the 32-bit memory space that could be mapped to 36-bit physical addresses= . I think this was platform specific code and I don=E2=80=99t know of any o= pen source version. The 32-bit Long Mode EFI does not have paging enabled, = so adding PAE means enabling paging yourself. 

The edk2 has the opposite version of this code so you can call 16-bit rea= lly mode (Legacy BIOS) from 32-bit Protected mode, or 64-bit Long Mode. Thi= s is the code to Thunk for 32-bit/64-bit mode to 16-bit code [2]/ 


Thanks,

Andrew Fish


Thanks
 



<edk2.png>
<= /div> --Apple-Mail=_BAA2F219-5CE0-4550-934E-69E8288CE212--