Hi, > > + /* read header */ > > + dma_memory_read(&address_space_memory, dma, > > + uv->buffer, sizeof(*mhdr), > > + MEMTXATTRS_UNSPECIFIED); > > Depending on DMA sounds appealing at first, but can fall apart in corner > cases. I know of 2 cases where DMA failed for me in the EC2 equivalent of > this: > > 1) SEV-SNP. If you want the hypervisor to implement UEFI variable services > for you, the buffer region must always be in shared state. Ensuring that > during boot time is tricky but doable. At runtime you no longer really have > control over the sharability of pages.
With SEV-SNP I don't see the point in using this. Why do you use confidential computing in the first place if you trust the host with your EFI variables? I'd rather see something simliar running under guest control, in svsm context. > 2) Mac OS X. MacOS is the only OS I'm aware of that really makes use of > relocation. They move your physical pages to random locations, give you a > non-1:1 mapping to that and once you're in real OS land, you have no more > knowledge at all about the physical location of anything. On the host side you have no insight into this indeed. The firmware knows all this very well though. The OS passes a mapping table to the firmware, efi runtime drivers can subscribe to mapping updates and can use RT->ConvertPointer to translate addresses from physical to virtual. The edk2 code (https://github.com/tianocore/edk2/pull/10695) does exactly that. I see your driver does that too, so in theory it should work just fine. I'm wondering what exactly the problem with macOS is? > Also, I'm surprised you cut the variable service off at the SMM boundary > instead of the RTS callback boundary. Why is that cleaner/better than > implementing variables completely in QEMU? Well, the variable service /is/ completely in qemu. See patch #6 which implements getvariable & friends. edk2 serializes the variable calls into a buffer and sends them over to the SMM side (or to qemu with the patches). I didn't feel like inventing a new serialization protocol if we already have a proven one in the edk2 code base. Also it is possible to send over more than just the variable call. There is a variable policy protocol implementation (patch #8), and we also get some events forwarded. More can easily be added should the need for that arise. > It would be nice to agree on a single external variable store implementation > :). It would be nice to have nitro support merged upstream, especially with BYOF coming. take care, Gerd
