From: Alexander Graf <graf@amazon.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, "Eric Blake" <eblake@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
qemu-arm@nongnu.org, "Michael Roth" <michael.roth@amd.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Ard Biesheuvel" <ardb@kernel.org>
Subject: Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c
Date: Wed, 12 Feb 2025 22:26:39 +0100 [thread overview]
Message-ID: <2c06a98c-f286-4632-a352-8b47dc4cc43c@amazon.com> (raw)
In-Reply-To: <4bwjwcs2k4hbrj6mokc57a5dy57jjssfxnvd4qm5257dgnid3x@yqdx7e47o2mf>
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
next prev parent reply other threads:[~2025-02-12 21:28 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 9:22 [PATCH v3 00/23] hw/uefi: add uefi variable service Gerd Hoffmann
2025-02-11 9:22 ` [PATCH v3 01/23] hw/uefi: add include/hw/uefi/var-service-api.h Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 02/23] hw/uefi: add include/hw/uefi/var-service-edk2.h Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 03/23] hw/uefi: add include/hw/uefi/var-service.h Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 04/23] hw/uefi: add var-service-guid.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 05/23] hw/uefi: add var-service-utils.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 06/23] hw/uefi: add var-service-vars.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 07/23] hw/uefi: add var-service-auth.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 08/23] hw/uefi: add var-service-policy.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 09/23] hw/uefi: add var-service-core.c Gerd Hoffmann
2025-02-11 9:45 ` Alexander Graf
2025-02-12 10:24 ` Gerd Hoffmann
2025-02-12 11:30 ` Alexander Graf
2025-02-12 12:28 ` Gerd Hoffmann
2025-02-12 13:45 ` Alexander Graf
2025-02-12 15:18 ` Gerd Hoffmann
2025-02-12 21:26 ` Alexander Graf [this message]
2025-02-13 9:28 ` Ard Biesheuvel
2025-02-13 10:06 ` Alexander Graf
2025-02-13 9:52 ` Gerd Hoffmann
2025-02-13 10:14 ` Alexander Graf
2025-02-13 14:54 ` Gerd Hoffmann
2025-02-13 22:25 ` Alexander Graf
2025-02-14 7:55 ` Gerd Hoffmann
2025-02-14 9:51 ` Alexander Graf
2025-02-14 11:16 ` Gerd Hoffmann
2025-02-14 12:22 ` Alexander Graf
2025-02-11 9:23 ` [PATCH v3 10/23] hw/uefi: add var-service-pkcs7.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 11/23] hw/uefi: add var-service-pkcs7-stub.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 12/23] hw/uefi: add var-service-siglist.c Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 13/23] hw/uefi: add var-service-json.c + qapi for NV vars Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 14/23] hw/uefi: add trace-events Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 15/23] hw/uefi: add UEFI_VARS to Kconfig Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 16/23] hw/uefi: add to meson Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 17/23] hw/uefi: add uefi-vars-sysbus device Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 18/23] hw/uefi-vars-sysbus: qemu platform bus support Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 19/23] hw/uefi-vars-sysbus: allow for arm virt Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 20/23] hw/uefi: add uefi-vars-isa device Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 21/23] hw/uefi-vars-isa: add acpi device Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 22/23] docs: add uefi variable service documentation Gerd Hoffmann
2025-02-11 9:23 ` [PATCH v3 23/23] hw/uefi: add MAINTAINERS entry Gerd Hoffmann
2025-02-13 9:41 ` [PATCH v3 00/23] hw/uefi: add uefi variable service Ard Biesheuvel
2025-02-13 10:11 ` Alexander Graf
2025-02-13 10:13 ` Ard Biesheuvel
2025-02-20 12:43 ` Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c06a98c-f286-4632-a352-8b47dc4cc43c@amazon.com \
--to=graf@amazon.com \
--cc=ardb@kernel.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).