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: Gerd Hoffmann
Subject: Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c
Date: Thu, 13 Feb 2025 15:54:42 +0100

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?

> 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.

take care,
  Gerd




reply via email to

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