Ethin wrote:
Could you tell me what version of the spec your looking at and what sections of that spec you found this information in? The latest UEFI spec says nothing about how SetVirtualAddressMap() is not recommended over something else. (It does indicate (only in section 1.2 as a side note) that the console support protocol "defines I/O protocols that handle input and output of text-based information intended for the system user while executing in the boot services environment," however.) For reference, I'm looking at chapter 8, but have searched the entire spec loking for "SetVirtualAddressMap" in particular, and found no such reference.
If you ask me about SetVirtualAddressMap() particularly, then the answer is it doesn't not recommend clearly, it just when you read and compare what one needs to do with and without calling that function, it becomes clear, that calling it is not worth of a try. Just read the description of SetVirtualAddressMap() and ConvertPointer() - when thinking on how many things should get fixed, it overwhelmes. it's a begging for troubles. also, there are passages like this, they leave a bit of confusion, the version 2.4.errata.b, section 2.3.6, page 39:
Quote:
In general, UEFI Configuration Tables loaded at boot time (e.g., SMBIOS table) can be
contained in memory of type EfiRuntimeServicesData (recommended and the system
firmware must not request a virtual mapping), EfiBootServicesdata,
EfiACPIReclaimMemory or EfiACPIMemoryNVS. Tables loaded at runtime must be
contained in memory of type EfiRuntimeServicesData (recommended) or
EfiACPIMemoryNVS.
So, what does this mean? these tables are recommended to be typed as runtime data and firmware "must not request virtual mapping"... So when you will decide to still call SetVirtualAddressMap() in this case, the tables will get innaccessible?
I mean, you still can use runtime services without all this burden. just ensure that with enabled paging, addresses left 1:1 mapped. in every section for calling convention for every supported architecture, the specification says something like this:
Quote:
• The system address regions described by all the entries in the EFI memory map that have the
EFI_MEMORY_RUNTIME bit set must be identity mapped as they were for the EFI boot
environment.
and then adds this:
Quote:
If the OS Loader or OS used SetVirtualAddressMap() to relocate the
runtime services in a virtual address space, then this condition does not have to be met.
For me it sounds like "man, why you would need that SetVirtualAddressMap() anyway?"
it's my impression, given how horrendously broken that "fixing up" could go. Imagine some crappy implementation of FW in the runtime driver stores pointers, say in some internal structure, dynamically placed somewhere inside of its data. FW could fixup addresses by the PE mechanism, thus those, for which there is relocation information. these dynamically stored pointers might get overlooked and left unfixed easily, with all the consequences. But on the other hand, calling this function for real is not necessary, because you just can identity map all Runtime Services and be happy.
If you ask about where I got about GOP not being available after ExitBootServices(), then it is in many places. For example in the description of ExitBootServices():
Quote:
No further calls to boot service functions or EFI device-handle-based protocols may be used, and the boot services watchdog timer is disabled.
more than enough.
I remember reading somewhere a more obvious hint on not messing up with establishing non-identity mapping for Runtime Services, but I didn't find it now. Nevertheless, I
think using it is not needed. you realize that you need to map every runtime typed region? then you need to rely on the FW fixing up every address in there. And, in the end of the day, it gives you absolutely nothing.