On 08/05/22 00:56, Jason A. Donenfeld wrote: > Hey Laszlo, > > On Thu, Aug 04, 2022 at 03:56:54PM +0200, Laszlo Ersek wrote: >> - do we want setup_data chaining work generally? >> >> - or do we want only the random seed injection to stop crashing OVMF guests? > > Preferably the first - generally. Which brings us to your point: > >>> Given we only need 48 bytes or so, isn't there a more subtle place we >>> could just throw this in ram that doesn't need such complex >>> coordination? >> >> These tricks add up and go wrong after a while. The pedantic >> reservations in the firmware have proved necessary. >> >> IIUC, with v2, the setup_data_base address would (most frequently) be 96 >> KB. edk2 does have uses for very low memory. If OVMF's PlatformPei does >> not reserve away the area, UefiCpuPkg or other drivers might allocate an >> overlapping chunk, even if only temporarily. That might not break the >> firmware, but it could overwrite the random seed. > > Yea, so we don't want an address that something else might overwrite. So > my question is: isn't there some 48 bytes or so available in some low > address (or maybe a high one?) that is traditionally reserved for some > hardware function, and so software doesn't use it, but it turns out QEMU > doesn't use it for anything either, so we can get away placing it at > that address? It seems like there *ought* to be something like that. I > just don't (yet) know what it is...
I don't know of any such "hidden pocket", unfortunately. On the other hand, low-level edk2 drivers (usually dealing with x86 intricacies, such as MTRRs, CPU bringup, ...) have repeatedly surprised me with their handling of low memory. Laszlo
