Laszlo I do not understand why you only set 4G page table for X64 PEI. But if X64 PEI only fills 4G page table by default, you can setup page fault handler to dynamic fix the address. That is the way how we handle full memory access in memory constrain environment, like SMM.
Also, this platform can choose not report above 4G memory as tested for DxeCore and report big enough ACPI/Reserved memory in MemoryTypeInformation table. Then DxeCore will allocate BIN below 4G and all ACPI/Reserved memory allocation will happen below 4G. We do not want to introduce a new PCD, because it is unnecessary burden to maintain a new one, especially we already have solution to handle most cases. Thank you Yao Jiewen From: Laszlo Ersek [mailto:[email protected]] Sent: Tuesday, February 23, 2016 5:04 PM To: Yao, Jiewen; Ard Biesheuvel Cc: Ni, Ruiyu; [email protected]; Tian, Feng; Zeng, Star; [email protected]; [email protected]; Fan, Jeff; Gao, Liming Subject: Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed On 02/23/16 05:31, Yao, Jiewen wrote: > I discussed with Module owner. Below is summary for MdeModulePkg: > > 1) PCD Name: We suggest to use PcdDxeIplSwitchToLongMode as > indicator that PEI is 32 bit and DXE is 64 bit for X86 platform. It > might be not clear stated in PCD description, but it is the intent > when this is introduced. We suggest to define this to be FALSE for > ARM, so that our core module can use it. (Confirmed with Liming Gao) > > 2) AcpiTableDxe: As Star Zeng mentioned, we need make sure FACS is > allocate below 4G when PcdDxeIplSwitchToLongMode is set, because it is > used by S3Resume. This is not good enough. PEI might be restricted to the first 4GB of memory *even though* it is built for X64. Consider a platform with the following characteristics: - PEI is X64 - DXE is X64 - hence PcdDxeIplSwitchToLongMode is FALSE - PEI has page tables only for the first 4GB of RAM - S3 is supported If AcpiTableDxe keyed off of PcdDxeIplSwitchToLongMode *solely*, in order to see whether the FACS needs to be allocated under 4GB, then said platform would break. The most frequently used build of OVMF is exactly like written above. > > 3) UefiBootManagerLib: As Ruiyu Ni mentioned, we need make allocate > L"PerfDataMemAddr" below 4G for when PcdDxeIplSwitchToLongMode is set, > because it is used by S3Resume. My counter-argument is the same as above, I think. > > > > 4) BootGraphicsResourceTableDxe: There is no need to add 4G > limitation, we can remove that directly. (Confirmed with Chao Zhang) > > 5) FirmwarePerformanceDataTableDxe: We can check > PcdDxeIplSwitchToLongMode to allocate Below4G memory for > mAcpiS3PerformanceTable which is used in S3. Same counter-argument again. > And we can remove 4G > limitation for mAcpiBootPerformanceTable directly. (Confirmed with > Chao > Zhang) > > 6) PiDxeS3BootScriptLib: We can check PcdDxeIplSwitchToLongMode for > S3TableBase and NewS3TableBase which is used in S3. (Confirmed with > Star > Zeng) Same counter-argument. > > 7) BootScriptExecutorDxe: We can check PcdDxeIplSwitchToLongMode for > FfsBuffer and BootScriptExecutorBuffer which is used in S3. (Confirmed > with Star Zeng) Same counter-argument. > > 8) CapsuleRuntimeDxe: Already check PcdDxeIplSwitchToLongMode.No > update needed. (Confirmed with Star Zeng) The only reason this doesn't break under OVMF is because OVMF doesn't implement capsule updates. In summary, PcdDxeIplSwitchToLongMode==TRUE implies, but is not equivalent to, the requirement to allocate under 4GB for S3 purposes. A platform may have *both* S3 *and* a 64-bit PEI phase without access to >= 4GB memory. That's why I proposed a brand new PCD. PcdDxeIplSwitchToLongMode would imply that PCD, but the new PCD wouldn't necessarily imply PcdDxeIplSwitchToLongMode. > BTW: We are trying not use IntelFrameworkModulePkg. If there is > replacement in MdeModulePkg, we suggest use the one in MdeModulePkg, > for example, BDS or ACPI. Absolutely, but migrating a platform from IntelFrameworkModulePkg BDS to MdeModulePkg BDS is not trivial, due to lack of documentation and examples; plus some functionality that is publicly available from GenericBdsLib (and is used by PlatformBdsLib instances) needs to be exported from the new boot manager library. Thanks Laszlo > > > > Thank you > > Yao Jiewen > > > > > > *From:*Ard Biesheuvel [mailto:[email protected]] > *Sent:* Monday, February 22, 2016 8:43 PM > *To:* Yao, Jiewen > *Cc:* Ni, Ruiyu; Laszlo Ersek; > [email protected]<mailto:[email protected]>; Tian, Feng; > Zeng, Star; [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Fan, > Jeff; Gao, Liming > *Subject:* Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: > only allocate below 4 GB if needed > > > > On 22 February 2016 at 13:40, Yao, Jiewen wrote: >> I did a search on current MdeModulePkg. I found there are more >> modules allocating Below4G memory. >> >> Besides BDS, we have BootGraphicsResourceTableDxe, >> BootScriptExecutorDxe, FirmwarePerformanceDataTableDxe, >> PiDxeS3BootScriptLib, CapsuleRuntimeDxe. >> >> >> >> BootGraphicsResourceTableDxe – I am not clear. >> >> CapsuleRuntimeDxe – Below4G is designed for PEI capsule. Or we do not >> need such capability. >> >> BootScriptExecutorDxe, FirmwarePerformanceDataTableDxe, >> PiDxeS3BootScriptLib >> - data need to be access in PEI phase. >> >> >> >> I think we might need more clean up for 32bit PEI. >> > > Agreed. > >> I am still thinking if we can reuse old Pcd – we can clarify in PCD >> description – it is only for 32bit PEI and 64bit DXE. >> >> Or a new PCD, and name to Pcd32BitPei? Please allow me collect more >> feedback on that. >> > > OK > >> In order to separate 32bit PEI issue from ACPI issue, I think we can >> check in ACPI patch at first, if you want. >> > > Should I wait for the maintainers of MdeModulePkg to give their > Reviewed-by ? > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
