On 02/18/16 15:20, Yao, Jiewen wrote: > Hi > Thanks to bring this 4G issue again. I have several thought for your > consideration. > > 1) At 12/16/2015, Samer El-Haj-Mahmoud <samer.el-haj-mahm...@hpe.com> > submitted a patch: > [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get > installed above 4GB > > Some ARM systems do not have available memory below 4GB, and still support > ACPI. This patch allows the tables to get loaded above 4GB if the allocation > below 4GB fails. > > I have given comments that: > -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe. > > -- Can we create a new function to allocate <4G at first, if fail, allocate > any memory? > Then we can update all caller to consume this new function. > We can avoid adding ERROR check anywhere. I also suggest we need add some > debug message there, we can add into one place. > > It is just another option to resolve ARM issue. Currently, we only add PCD > when necessary, because we got complain that we defined too many PCDs. > If there is a way to avoid introducing a new one. It worth considering.
I agree it's a good idea to consider solutions that avoid adding new PCDs. ... Ard mentioned that in some cases, even if it's possible to allocate under 4GB, it is detrimental to performance. (Please see the first link below for more information.) So "always start low" is probably not a bullet-proof strategy. > 2) I believe 4G table issue not only exist in ACPI table, but also exist in > others. For example, Smbios table. > SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G > limitation. > > I know ACPI table and SMBIOS table are different. Some platforms care only > one of them. > Personally, I hope we can have a consistent way to resolve this generic 4G > issue. > > I have seems SMBIOS table is using the way Samer submitted in last year. > (Allocate <4G at first, if fail, allocate at any place) > Do you see any limitation on this algorithm? The universal SMBIOS driver already allows the platform to control this through an existent PCD. Please see these patches / comments: http://thread.gmane.org/gmane.comp.bios.edk2.devel/7752 http://thread.gmane.org/gmane.comp.bios.edk2.devel/7759 > I am not insist on some solutions. I just want to bring the other way for > discussion. One important difference I see between SMBIOS and ACPI is the following (and please correct me if I'm wrong): it seems that the 32-bit vs. 64-bit entry points for SMBIOS are distinguished not only by the SMBIOS spec(s), but also by UEFI itself -- they are associated with different GUIDs in the system config table. Whereas for ACPI, the same GUID is usable by platforms independently of whether they will expose RSDT or XSDT. I feel that these cases should be sharply distinguished from each other on the UEFI spec level -- maybe not with different GUIDs (for the RSDP), but with a new interface or protocol version that explicitly allows for more control from the platform. Thanks Laszlo > BTW: I am not clear on memory map on >4G ARM platform. Can someone help me > understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G > or <4G? > > Thank you > Yao Jiewen _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
