qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c


From: Alexander Graf
Subject: Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c
Date: Wed, 12 Feb 2025 22:26:39 +0100
User-agent: Mozilla Thunderbird


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.


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?


Not sure how to do that best on x86 though.  Find 64k unused address
space over ioapic?  Do we have enough free space there?  And how
future-proof would that be?


I'm not worried yet about where we place that memory, but more about ensuring that we actually have a working path to access it. We can always find space in the PCI hole, as long as we properly advertise it to all stakeholders via ACPI and memory map.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]