On 13.02.25 10:28, Ard Biesheuvel wrote:
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.
Correct, which is what boot.efi does. That mapping only tells firmware
about the change from old VA -> new VA though.
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.
The spec says that calling SetVirtualAddressMap is optional from the
firmware's point of view. A boot loader may call it - and even depend on
its functionality. The spec even goes further and almost endorses the
case boot.efi does:
The call to SetVirtualAddressMap() must be done with the physical
mappings. On successful return from this function, the system must
then make any future calls with the newly assigned virtual mappings.
All address space mappings must be done in accordance to the
cacheability flags as specified in the original address map. [...]
You can absolutely read that paragraph as "From here on, only virtual
mappings matter".
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.
I halfway agree. It's fairly trivial to make x86 Mac OS X work with
stock edk2 [1]. All you need are a few boot services, a non-standard way
(or BootXXX variables) to find the real boot binary and APFS driver
(binary is included in every APFS FS) load support. The rest is a fairly
standard compliant UEFI environment.
But I'm not sure how that's relevant to the argument that we need a way
to perform runtime service calls without relying on DMA? In addition to
the potential VA/PA mismatch issue, relying on DMA from RTS can quickly
also get broken for any confidential compute environments where you need
to take explicit action to make memory visible to the hypervisor.
All I'm asking for is an (optional) viable path that works without DMA :).
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)
For something as core as a UEFI variable service that should become the
default in a generic platform like QEMU, I don't think we should rely on
new additions to the UEFI spec :(. Users want to be able to run old
Operating Systems.
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)
The non-hacky alternative would be to expose a real 64KiB large MMIO
window into host memory that goes through full instruction emulation for
every access. Then we could expose it as real MMIO target memory to RTS
which should always work. DMA can then be an (optional) optimization on
top to copy to/from that buffer.
Alex
[1]
https://github.com/tianocore/edk2/compare/vUDK2018...agraf:edk2:vUDK2018-AppleSupportPkg
