On Wed, 12 Feb 2025 at 22:26, Alexander Graf <g...@amazon.com> wrote: > > > On 12.02.25 16:18, Gerd Hoffmann wrote: > > Hi, > > > >>> Yes. Knowing both physical and virtual address works only for memory > >>> you allocated yourself before ExitBootServices. So you can't pass on > >>> pointers from the OS, you have to copy the data to a buffer where you > >>> know the physical address instead. Yes, some overhead. Should still > >>> be much faster than going to pio transfer mode ... > >> MacOS takes over the full physical address map past ExitBootServices: Your > >> code no longer has VA access to random code > > That is totally fine. EFI drivers must register everything they need as > > runtime memory. Anything else can be unmapped by the OS when calling > > EFI services. > > > >> and it literally memcpy()'s all preserved (virtual available) code and > >> data to different physical addresses. > > Uhm. I have my doubts this copying behavior is blessed by the UEFI spec. > > > I don't remember anything in the spec prohibiting it. >
The UEFI spec clearly states that runtime services must either be called using a 1:1 mapping, or via a virtual remapping but in that case, SetVirtualAddresMap() must be called to inform the firmware of the new virtual mapping. Even if this is not clearly stated, this violates the intent of the UEFI spec: the code reasons about mappings of physical memory, implying that the mapping is the only thing that changes. Moving memory contents around can only be done safely after SetVirtualAddressMap(), making it mandatory on these systems, whereas the spec clearly states that it is entirely optional. But whatever OSX does on x86 is irrelevant anyway: it is vertically integrated with the firmware, which is vaguely EFI based but does not aim for spec compliance. The OSX EULA does not permit running it on anything other than Apple hardware. And x86 Apple hardware will be reaching obsolescence pretty soon, at least where future development is concerned. My colleague filed a USWG proposal for a EFI_MEMORY_SHARED attribute that must be honored by the OS when creating runtime mappings, and map the region in a way that allows access by another observer (typically the VMM but semantically it could mean other things too) > > >> You simply have nothing that is all of 1) RAM (mapped as cacheable on > >> ARM), 2) known VA 3) known PA. > > Bummer. > > > >> So we really really need a fallback mechanism that works without DMA > >> :). > > On arm it should be relatively simple to move the buffer to device > > memory. Just place one more region on the platform bus, advertise > > address + size via device tree, done. > > > That will bring back all issues with cached vs non-cached memory > accesses, no? So edk2 will always access that memory as device memory > which means it bypasses the cache, while QEMU will access it through the > cache. So that buffer would need to actually be MMIO memory I suppose? > Indeed. Presenting memory as MMIO just to trick the guest into mapping it shared is not the right approach here, which is why we need EFI_MEMORY_SHARED on ARM. On x86, using the EfiMemoryMappedIo type happens to work, but it is a hack (e.g., you cannot allocate memory of this type)
