On 1/25/19 10:43 PM, Ard Biesheuvel wrote: > On Fri, 25 Jan 2019 at 19:21, Heinrich Schuchardt <[email protected]> wrote: >> >> On 1/23/19 6:33 PM, Alexander Graf wrote: >>> While discussing something compeltely different, Ard pointed out >>> that it might be legal to omit calling SetVirtualAddressMap altogether. >>> >>> While that sounds great, we currently rely on that call to remove >>> all function pointers to code that we do not support outside of >>> boot services. >>> >>> So let's patch out those bits already on the call to ExitBootServices, >>> so that we can successfully run even when an OS chooses to omit >>> any call to SetVirtualAddressMap. >> >> Such an operating system would not be allowed to use any virtual >> addresses at any time because runtime drivers would not be informed >> about the mapping. >> > > No. The OS would be permitted to invoke the runtime services at their > original offset. > > For arm64, this is trivially achievable, since we already use userland > mappings for the runtime services. On 32-bit architectures, it is more > complicated, since the boot time mapping of peripherals and/or memory > may conflict with the kernel's layout of the address space (e.g., if > your NOR flash lives above 0xc0000000, you *have* to remap it for the > runtime services to be able to use it). > > > >> Does such an operating system exist? >> Or is this only a hypothetical case? >> >>> >>> Reported-by: Ard Biesheuvel <[email protected]> >>> Signed-off-by: Alexander Graf <[email protected]> >> >> I am missing a description of the side effects of the change, e.g. >> >> Our EFI unit tests call the Reset() service. >> >> So Python tests will fail on systems that do not implement Reset() in a >> runtime compatible manner. >> > > All runtime services (except SetVirtualAddresMap() and > ConvertPointer(), obviously) may be used at runtime with or without > installing a virtual address mapping. >
With this patch in place Travis CI testing fails: After 'bootefi selftest' this output is not ejected: m = u_boot_console.p.expect(['resetting', 'U-Boot']) And after the reset U-Boot crashes (observed for qemu-arm64_defconfig). Best regards Heinrich _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
