> On Dec 22, 2014, at 10:02 AM, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
>
> On 22 December 2014 at 18:34, Leif Lindholm <leif.lindh...@linaro.org
> <mailto: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()
>
Exactly the OS can have extra stuff mapped as long as the EFI RT is 1:1, but
the spec leaves that up to implementation. The interaction between the OS and
FW is the minimum required to get the job done, and that is by design.
Just because something works on a given system does not mean the code is
following the spec. The same way you can have a bug in your C code that has
seemed to work forever and then all of a sudden starts crashing.
Thanks,
Andrew
> --
> 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
------------------------------------------------------------------------------
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
