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

[Alexander Graf <graf@amazon.com>]

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