miczyg1
commented
1 year ago We could include the RamDisk driver into UEFI Payload, but I would need some clear procedures how it i supposed to be used on some real examples.
I can see that HTTP boot uses the RamDisk driver for some virtual CD or virtual disk.
I know that certain Power States like S3 Sleep does not touch RAM contents and keeps it powered on so its contents remain intact, so a RAM Disk that survives warm reboots seems theorically possible... it may be important to document what does NOT make the computer to lose RAM Disk data if relying heavily on this feature
Anything that does not do power-cycle (so a simple reboot/reset) will not clear the memory and the RamDisk content will be present in the RAM. Intel TXT sometimes requests full memory clear. But one would need some additional software that will search for the RamDisk in its previous location (wherever it was allocated and placed in memory). So it is not just that simple. I can only see some specific and custom use cases here, so we can provide the necessary drivers to handle RamDisks from UEFI side, but the rest is up to the user.
zirblazer
desowin
The problem you're addressing (if any) The problem is when you have too much RAM and don't know what to do with it :D
Describe the solution you'd like Adding a RAM Disk Driver that allows the Firmware to reserve a certain capacity of physical RAM to create a Block Device that is seen by the OS as a fixed Disk Drive. While it is usually possible to do this OS-side and I don't find it very useful for Linux (Due to having tmpfs and brd Driver support easily available), creating a RAM Disk from within Firmware for Windows will remove the need to having to use third party tools to do so, so it may be more convenient.
Where is the value to a user, and who might that user be? It depends on an actual use case, ease of use, and performance characteristics. Most people don't really benefit from a dumb RAM Disk if they have to do manual backup of the RAM Disk contents, but it was recommended for things like browser Cache or other stuff that may actually benefit from being volatile. A Firmware-side RAM Disk seems convenient.
Describe alternatives you've considered Using a third party RAM Disk generator.
Additional context OVMF already provides a RAM Disk Driver, albeit I never tested it to see what it does and how it can be improved. Nor I have hear about it being used in bare metal contexts.
The usefulness of the RAM Disk heavily depends on whenever it can be possible to make it non volatile on reboots. For example, installing an OS will always force a reboot at some point, so a bare metal RAM Disk for installing OSes isn't really viable (I did tested a Linux-created RAM Disk in a host to use for a QEMU VM where I could bypass the reboot issue, and it was... interesing, from a performance standpoint). I know that certain Power States like S3 Sleep does not touch RAM contents and keeps it powered on so its contents remain intact, so a RAM Disk that survives warm reboots seems theorically possible. Also, rebooting so far seems inconsistent because I have seen many cases where a reboot is an automatic power cycle instead of a warm reboot, so it may be important to document what does NOT make the computer to lose RAM Disk data if relying heavily on this feature.
The performance of RAM Disks varies a lot: https://www.raymond.cc/blog/12-ram-disk-software-benchmarked-for-fastest-read-and-write-speed/ Given than Firmware should be able to provide the lowest-level possible setup for the RAM Disk (Since it can allocate the RAM for it then tell the OS than it has less RAM than physically installed), I would expect that it should be the most flexible one. I'm not sure if a virtual controller or whatever the OS thinks that manages the RAM Disk could be made to use Huge Pages or any other interesing performance trick.
Note than most of these tools can format the RAM Disk they generate thus from an user perspective they are ready to use, which may be needed to do from within Firmware since formatting the RAM Disk everytime it is created OS side before using can become a chore. I'm not intending than Firmware matches certain capabilities like automatic backup and restore of the RAM Disk contents on shut down and on, just creating it and not zeroing the allocated RAM on warm reboots is enough for basic functionality.
Also, a RAM Disk may be useful to do things like provide a virtual Drive with Drivers. For example, other propietary Firmwares relies on the WPBT (Windows Platform Binary Table) ACPI Table to conveniently provide Drivers for Windows to install (Which may be VERY useful for basic network connectivity, so NIC / WiFi Drivers), but its nature makes than the installer is executed in every boot, and it may automatically install things the user does not want. Creating a small dumb RAM Disk, uncompressing an internal ZIP on it, then let the user to manually point Windows to the Drivers is a less invasive way to achieve the same.