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
