platform: Add abstractions for request processing #571
Conversation
To facilitate platform abstraction, split requests.rs into: - kernel/src/sev/caa.rs: implementation for the SVSM Calling Area - kernel/src/platform/snp_requests.rs: SEV-specific request processing No functional change intended. Signed-off-by: Peter Fang <[email protected]>
Add new abstractions to SvsmPlatform: - request_task() is the kernel task for request processing - request_loop() is the main vCPU request loop Only SEV-SNP platforms do useful things in their implementations right now. Signed-off-by: Peter Fang <[email protected]>
Right now there is nothing to be done for setup_percpu() and setup_percpu_current(). Just return Ok() so they don't error out. Signed-off-by: Peter Fang <[email protected]>
Some functions have no need to be exposed externally so turn them private. Signed-off-by: Peter Fang <[email protected]>
peterfang
force-pushed
the
request-loop
branch
from
9773714 to
a77ba8a
Compare
|
Moving request processing to the platform implementation is not the right approach. The request-processing logic will at some point move to user-space, where the init process will decide, based on a feature detection mechanism, which services to run. The right way to start here is to implement a basic version of that feature detection logic and then only start the request processing thread if running on an AMD platform. The outcome is the same as with moving stuff to the platform logic, but overall things are more generic with feature detection. This is important because at some point there will also be AMD systems running a device model and not the standard request processing. A feature-based model can be more easily extended to support that. |
Understood. This totally makes sense. Should we start this work from the |
Add new abstractions to SvsmPlatform:
Also, return Ok() for setup_percpu* on TDP platforms so they don't error out.