All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 13 Feb 2025 23:25:06 +0100	[thread overview]
Message-ID: <342a1bd9-52e9-4a6d-8a2a-63d2b478d896@amazon.com> (raw)
In-Reply-To: <jnxvyw6q4vkng7jztu7q5rabgeohhpoxojdn4wt6xckc6pzmqz@ateji77pl5j7>


On 13.02.25 15:54, Gerd Hoffmann wrote:
> On Thu, Feb 13, 2025 at 11:14:03AM +0100, Alexander Graf wrote:
>>> 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.
> Hmm.  Played around with the device memory approach a bit today.  Looks
> workable for both arm/sysbus and x86/isa.  Problem is, if that does
> leave any unsolved corner cases on the table it doesn't buy us much, and
> the arm caching issues start to make me a bit nervous ...
>
> So, maybe allowing pio data transfers is the better approach after all.
>
> How do your patches pick the transfer mode?  Is that dictated by the
> host?  Or is the guest free to choose?  In case of the latter:  How does
> the guest decide what to do?


In our version, the guest gets to pick. It defaults to the DMA interface 
unless it detects that it's running either the macOS logic (a case you 
can ignore for now) or is running with SEV-SNP.

I think for the upstream interface, it would be best to have the host 
indicate which one it recommends the guest to use. That way you can 
force the fallback path without requiring tedious edk2 changes.


>
>> Yes, IIRC we advertise where the hole is. I'm sure we can find a spot.
>> Somewhere next to the HPET :).
> 0xfef1000 seems to be free, which is kida fun b/c of the 'ef1' in the
> address.


True, I love it! :)

It's not enough address space to fit the full 64k buffer though, right? 
Would all of 0xfef00000 be free by chance? Then you could just direct 
map the transfer buffer there.


Alex


  reply	other threads:[~2025-02-13 22:25 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
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 [this message]
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=342a1bd9-52e9-4a6d-8a2a-63d2b478d896@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.