Yes. We have received feedback on lack of clarity regarding many memory attributes in the UEFI & PI spec (e.g., capability versus settings, etc). I'll work w/ the UEFI Forum to clarify in upcoming errata on those documents. Vincent
-----Original Message----- From: Yao, Jiewen [mailto:jiewen....@intel.com] Sent: Monday, June 29, 2015 6:22 AM To: Laszlo Ersek; Ard Biesheuvel Cc: Fleming, Matt; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] BUG in properties table feature implementation The white paper is @https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Practices_with_UEFI.pdf We documented the OS limitation, like Win8, and we hope future OS can resolve it. (So did Win10) (We also listed some other potential limitation on PE/COFF image parsing in existing firmware.) I agree that it is better idea to clearly document the requirement in UEFI spec. Answer last 2 questions: - what's the reason for "PropertiesTableEnable" being just a boolean PCD, not a feature one? Is it expected to be set dynamically (perhaps based on processor features)? "Feature PCD" is fixed at build time. We thought it might be enable/disable via setup option, based on platform choice. "PCD" means it can be configured as static (fixed at build time) or it can be configured as dynamic (updatable at runtime). - shouldn't it be called *Pcd*PropertiesTableEnable? Yes. It seems we forget to add *Pcd* keyword. Thanks! Thank you Yao Jiewen -----Original Message----- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Monday, June 29, 2015 9:07 PM To: Ard Biesheuvel; Yao, Jiewen Cc: edk2-devel@lists.sourceforge.net; Gao, Liming; Justen, Jordan L; Kinney, Michael D; Zeng, Star; Fleming, Matt Subject: Re: BUG in properties table feature implementation On 06/29/15 14:44, Ard Biesheuvel wrote: > On 29 June 2015 at 14:34, Yao, Jiewen <jiewen....@intel.com> wrote: >> Hi Ard >> Yes, your are right. We do observe similar odd behavior in old >> Win7/Win8/Win8.1, and we have to disable it. >> Win8 and Win8.1 have OS patch to set adjacent virtual memory map, to resolve >> this issue. > > I see this as a big problem with the feature, as it breaks backward > compatibility. IOW, you won't be able to boot Windows 7 on a UEFI 2.5 > system unless you manually disable the feature (in the setup screen, I > suppose?) > >> We also tested Win10, and Suse 11 GM. They are good. >> >> Would you please share the information on which OS you are using? >> > > I am using the upstream Linux kernel for AArch64. I am not using a > distribution. If the SUSE kernel is using a patch for this, then I hope it was at least *submitted* to lkml / linux-efi? >> All in all, if OS cannot guarantee the virtual memory map is >> adjacent, we have to disable this feature. >> > > This is backwards: the feature should be implemented such that it > cannot be trivially broken by a well-behaving OS. Note that nothing in > the SetVirtualAddressMap () implementation suggests that the regions > should be adjacent. > > Perhaps it would have been better to introduce a new memory region > type EfiRuntimeServicesPecoffData, so the OS at least knows which > regions it should keep adjacent, (i.e., Code and PecoffData regions > should be kept together) > > So does PE/COFF even allow the memory image to deviate from the file > image? If so, the correct way is to update the PE/COFF loader and the > relocation logic can deal with sections being laid out differently in > memory than they are in the file. > I agree. If there's a new requirement on the OS or boot loader with regard to mapping UEFI memmap ranges, that should be spelled out in the UEFI spec. I tried to check, and at the moment the UEFI spec seems neither buggy nor theoretically impossible to implement in the firmware. If the spec is deemed complete at this point, then the relocation logic needs improvement. I did see Matt's question in the mantis ticket <https://mantis.uefi.org/mantis/view.php?id=1224>, and Vincent's answer that a new whitepaper would be released. Still that doesn't substitute for clarity in the spec, or more complete implementation, in my opinion. In any case, for OVMF, I think we'll need a small patch that disables this feature (if for nothing else, then to quell the noisy warnings about "the section alignment being != 4 KB"). I'm adding that to my queue (but anyone please feel free to do it while I'm offline). Two more questions: - what's the reason for "PropertiesTableEnable" being just a boolean PCD, not a feature one? Is it expected to be set dynamically (perhaps based on processor features)? - shouldn't it be called *Pcd*PropertiesTableEnable? Thanks Laszlo ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
