Add Salus-TSM stub #129
Add Salus-TSM stub #129
Conversation
atulkharerivos
force-pushed
the
topic/salus_tsm
branch
from
afdda95 to
e351525
Compare
|
Looks like a squashing error on commits 3 and 4? Also can we have a slack discussion about splitting in to two vs adding an optional mode to the existing binary? |
atulkharerivos
force-pushed
the
topic/salus_tsm
branch
from
e351525 to
09b1120
Compare
This adds a feature flag that can be conditionally used to compile code specific to Salus-TSM (or alternatively exclude code that's not needed for the functionality). The Salus-TSM binary will be loaded early by the platform-FW, and is intended for use with a HS-mode VMM.
This refactors the host_vm functionality and moves most of it into a seperate module. It also introduces a tsm_core module to contain functionality that will be shared by the Salus version that supports VS-mode guests, and the Salus-TSM version that will support HS-mode VMMs.
This adds a module for the Salus TSM binary. At present, the it's a stub intended for use prototyping purposes, and will evolve to provide the complete range of functionality.
This makes the changes to Cargo.toml and the Makefile to build binaries for the original Salus, and the new Salus-TSM.
atulkharerivos
force-pushed
the
topic/salus_tsm
branch
from
09b1120 to
feaed3d
Compare
There was a problem hiding this comment.
Hm, I'm not sure separate binary targets + feature flag is the way to go, unless the binary targets can implicitly select the correct value of the feature flag.
I'm not a huge fan of the "Salus" vs "Salus-TSM" naming as they're both TSMs, but the former has the ability to load & run the host in VS while the latter is just a TSM that expects the host to be load & run independently. It would be better to name them after the deployment models they are to be used in (host-in-VS vs host-in-non-TEE-HS), but I don't have a good suggestion at the moment :)
| @@ -0,0 +1,526 @@ | |||
| // Copyright (c) 2021 by Rivos Inc. | |||
There was a problem hiding this comment.
(general comment on this file)
There's quite a lot here that isn't really about the "host VM" or even the "host-in-VS" deployment model, for example: setting up CSRs, building a memory map, setting up a heap, setting up paging(*). It feels like much of this can remain in main or tsm_core. Anything that's related to the loading and running of the host VM could be placed in host_vm_loader.
*both will need paging, but obviously there will be differences in how it's set up.
| path = "src/salus_tsm.rs" | ||
| required-features = ["salustsm"] | ||
|
|
||
| [[bin]] | ||
| name = "salus" | ||
| path = "src/main.rs" |
There was a problem hiding this comment.
Instead of main.rs and salus_tsm.rs, can we put main in both names so that it's obvious that they're both the "main" modules of their respective binaries?
| run_salus_tsm: salus_tsm | ||
| $(QEMU_BIN) \ | ||
| $(MACH_ARGS) \ | ||
| -kernel $(RELEASE_BINS)salus-tsm \ | ||
| $(EXTRA_QEMU_ARGS) |
There was a problem hiding this comment.
We should probably have an internal discussion about how this Makefile target is expected to be used.
There was a problem hiding this comment.
Sure..will add this and the below to the thread.
| @@ -10,6 +10,9 @@ strip = "debuginfo" | |||
| codegen-units = 1 | |||
| panic = "abort" | |||
|
|
|||
| [features] | |||
| salustsm = [] | |||
There was a problem hiding this comment.
If there are separate binary targets, do we still need a feature flag? If we want a feature flag + separate binary targets, is there a way to automatically set the feature based on which binary we're building?
Also some bikeshedding: I feel like "tsm_only" is a better name than "salustsm", as it's more obvious what the flag is doing (stripping out the non-TSM components).
There was a problem hiding this comment.
Feature flags can be enabled by default, but it does require the flag to be defined AFAIK. The nomenclature was arbitrary, so perhaps, we can just see what feels best in the channel.
This adds a new binary target for the Salus-TSM. The Salus-TSM binary will be loaded early by the platform-FW, and is intended for use with a HS-mode VMM.
At present, the binary is a stub intended for use prototyping purposes, and will evolve to provide the complete range of functionality.
Note that we can have the a single main.rs, and have two different [[bin]] targets with the feature flag, but cargo emits a warning about it (which will likely cause the CI to fail).