On 22 December 2014 at 18:34, Leif Lindholm <leif.lindh...@linaro.org> wrote: > On Mon, Dec 22, 2014 at 09:08:36AM -0800, Andrew Fish wrote: >> > An issue has come up while developing the EFI support for the arm64 >> > linux kernel, in particular the support for kexec which requires >> > changes with respect to how we handle the virtual to physical mapping >> > of runtime services. >> > >> > My question is: is it legal for SetVirtualAddressMap() [which is >> > called using a 1:1 mapping as per the spec] to already dereference >> > those virtual addresses before it returns itself? My assumption would >> > be no, as it would require two mappings to be active at the same time, >> > implying that those mappings should never overlap. However, the spec >> > is not explicit about this in the text, >> >> It is hard for the spec to tell you what not to do as the surface are of >> that is very large, the spec focus on telling you what is required. > > But if the behaviour Ard is describing is permitted as per the spec, > must the spec then not also state that all virtual mappings being > requested are required to be present and active in the memory map? > > I can not find any instance stating this. Which can be interpreted as > an implicit ban on touching the virtual mappings before > SetVirtualAddressMap() returns. > > Or have I missed something? >
No, I don't think you have. The spec mentions that the UEFI core first signals the address change event to all drivers before reapplying the PE/COFF fixups, which means all statically allocated data (global variables) is converted after the driver itself is done handling the event, and the driver is effectively in a limbo state during this entire time, and any kind of processing it does other than calling ConvertPointer() on its private pointers is potentially problematic. Also, the implied requirement to have both 1:1 and virtual mappings active at the same time results in an additional requirement that the 1:1 mapping and the virtual mapping must not overlap, which is a complication in any case, but especially cumbersome on 32-bit architectures which UEFI also supports (due to the densely populated physical memory space) So my conclusion is that accesses through the newly installed virtual pointers during SVAM() consitute a bug, and are not something the OS should care about when calling SVAM() -- Ard. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
