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]; 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 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
