On 13.02.25 10:52, Gerd Hoffmann wrote:
Hi,
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?
I don't think so. The firmware driver knows this actually is normal ram
and can setup mappings and memory attributes accordingly. The situation
is a bit different from vga memory bars which are handled by pci bus
management which doesn't know anything about virtualization specifics.
Well, unless macos thinks it knows everything better and goes setup
uncached mappings ...
It's not only macOS. After SetVirtualAddressMap, the OS owns the virtual
address space of Runtime Services. So in theory it also owns
cacheability attributes of all mappings.
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.
Well, the host can't easily place stuff in the pci hole because the
guest will manage that (map pci bars etc). But making the pci hole
a bit smaller to make room is an option I think.
Yes, IIRC we advertise where the hole is. I'm sure we can find a spot.
Somewhere next to the HPET :).
Alex
