Initial implementation for a RAM filesystem #27
Conversation
There was a problem hiding this comment.
Looks good. I just had one thought:
If the pre-built filesystem image is going to contain a significant volume of files then unpacking the entire filesystem into RAM on every boot may not be efficient. Would it make sense to implement a read-only filesystem using the same interface over the top of something like the firmware file system that OVMF uses? RamFS could then be reserved just for dynamic or modified files.
So the reason for the RamFS and unpacking is that the file-system contains the binaries we want to execute. Unpacking into a RamFS allows to execute them in-place, without copying the binary contents to a different memory location. But the underlying filesystem API allows multiple backend implementations. A DirEntry can point to any struct implementing the Directory trait, so that we can implement "mounting" of other file-systems, like a read-only FS that gives access to the firmware file system. The plan is to use the filesystem interface also for the persistency layer once that gets implemented. |
joergroedel
force-pushed
the
ramfs
branch
2 times, most recently
from
e2396ec
to
4a6a241
Compare
|
Population of RamFS is now implemented too and code is rebased to latest main branch. Moving this out of draft state now. |
Allow to add and subtract usize variables to and from the PhysAddr and VirtAddr types. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Zero the contents of the original secrets page to not leak any keys to the guest. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Re-add the page_align_up() and page_offset() functions as they are needed by the RamFS implemention. There they need to operate on offsets within pages, which are of type usize and not VirtAddr or PhysAddr. Signed-off-by: Joerg Roedel <jroedel@suse.de>
FixedStrings can only be compared with &str values. Also allow to compare them with other FixedStrings. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Make is possible to query the length of a FixedString. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Implement a structure which implements Clone, but not Copy, to track references to file pages. This way references to pages can be dropped automatically when a PageRef is released. Signed-off-by: Joerg Roedel <jroedel@suse.de>
When running unit-tests the virt_to_phys() and phys_to_virt() functions will cause panics because the address space is set up differently. Work around that by providing test-specific versions of these two functions. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Make sure file pages are zeroed before returning them to the caller. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Export unit-test specific functions which are used to setup a memory allocator for use in unit-test of other modules. This will be used in the file-system specific tests. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add a module for file-system implementations and start a generic API definition. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add an implementation for files stored in memory. This is the base for a ram file system. Also add a unit-test which reads and writes a RamFile. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Directories can contain files and other directories. Also add a unit-test to test the basic functionality. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add support to unlink files and directories. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Implement a RAM-based file-system for the SVSM to use and provide functions, structs and methods to interact with it. Initialize the FS from the svsm_main() function. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Add a function which will create a file, and with it all needed sub-directories. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Optionally add a file archive into the COCONUT binary which can be used to create a RAM file-system at runtime. Signed-off-by: Joerg Roedel <jroedel@suse.de>
The launch information was passed via registers from stage1 to stage2. This does not scale with the amount of information we need to pass up the boot chain, so put all information at the bottom of the stage2 stack. This included information about the kernel image in physical memory and a potential kernel fs archive. The latter is not used yet, but passed on to KernelLaunchInfo. Signed-off-by: Joerg Roedel <jroedel@suse.de> fix for launch stack
|
Updated the PR, all review comments received so far are now addressed. |
|
Looks like there are no major concerns left, I am going to merge this code soon. We can fix things on-top as they come to our attention. |
Add code to parse the archive file and populate the RamFS. The archive file format is still very simple and subject to change. Signed-off-by: Joerg Roedel <jroedel@suse.de>
Support for a RAM filesystem and introduction of a general filesystem interface into the SVSM code-base. The filesystem is populated from a packaged archive file at boot time. The archive file is optional for now and requires a separate tool to create.