openhcl_boot: snp: allow com3 serial#3376
openhcl_boot: snp: allow com3 serial#3376Brian-Perkins wants to merge 1 commit intomicrosoft:mainfrom
Conversation
|
This PR modifies files containing For more on why we check whole files, instead of just diffs, check out the Rustonomicon |
There was a problem hiding this comment.
Pull request overview
This PR updates openhcl_boot’s boot-time logger initialization to allow using the COM3 serial logger when running under AMD SEV-SNP isolation on x86_64.
Changes:
- Extend the x86_64 boot logger match arm to enable
Logger::SerialforIsolationType::Snpwhen COM3 is available.
| *logger = match (isolation_type, com3_serial_available) { | ||
| #[cfg(target_arch = "x86_64")] | ||
| (IsolationType::None, true) => Logger::Serial(Serial::init(InstrIoAccess)), | ||
| (IsolationType::None | IsolationType::Snp, true) => { |
There was a problem hiding this comment.
Enabling COM3 serial for IsolationType::Snp uses InstrIoAccess (raw in/out port I/O). In an SNP CVM these instructions typically trigger a #VC and require GHCB/GHCI plumbing/exception handling; this repo already avoids cpuid in SNP for that reason (see openhcl/minimal_rt/x86_64-config.toml:12-14) and main.rs notes there is no GHCB/GHCI page set up for isolated VMs (openhcl_boot/src/main.rs:818-827). As-is, this is likely to hang/triple-fault when serial is used under SNP. Consider keeping SNP on Logger::None until a GHCB-based IoAccess is implemented and initialized, or gate this arm on a verified SNP-safe I/O path being available.
|
Being curious if some new processors allow doing port I/O in that way with SEV-ES & SNP in VMPL0? The code runs at VMPL0, it would seem that the register state in inassessible to any other entity so cannot emulate port I/O. I mean at least things were that way... All told, sharing a page with the host and using the GHCB protocol did allow printing to com3 in SNP from the boot shim. It's here, perhaps still useful: #1378 |
No description provided.