Description of problem: sevctl ok returns 1 on SNP capable Milan and Genoa when host kernel doesn't support SNP Version-Release number of selected component (if applicable): sevctl-0.4.1-2.el9.x86_64 How reproducible: 100% Steps to Reproduce: 1. on Milan /Genoa, host kernel not support SNP # sevctl ok [ PASS ] - AMD CPU [ PASS ] - Microcode support [ PASS ] - Secure Memory Encryption (SME) [ PASS ] - Secure Encrypted Virtualization (SEV) [ PASS ] - Encrypted State (SEV-ES) [ FAIL ] - Secure Nested Paging (SEV-SNP) [ SKIP ] - VM Permission Levels [ SKIP ] - Number of VMPLs [ PASS ] - Physical address bit reduction: 6 [ PASS ] - C-bit location: 51 [ PASS ] - Number of encrypted guests supported simultaneously: 1006 [ PASS ] - Minimum ASID value for SEV-enabled, SEV-ES disabled guest: 10 [ PASS ] - SEV enabled in KVM: enabled [ PASS ] - SEV-ES enabled in KVM: enabled [ PASS ] - Reading /dev/sev: /dev/sev readable [ PASS ] - Writing /dev/sev: /dev/sev writable [ PASS ] - Page flush MSR: DISABLED [ PASS ] - KVM supported: API version: 12 [ PASS ] - Memlock resource limit: Soft: 8388608 | Hard: 8388608 Error: One or more tests in sevctl-ok reported a failure Expected results: sevctl return 0 on SNP capability Additional info:
In QA tests for 9.3 release, we found a "bug" in the way Genoa encodes SEV-SNP support. Not really a bug, but the SEV-SNP CPUID encoding is not the same as Naples, Rome, or Milan. Therefore, if Genoa is detected, we need to check SEV-SNP in "Genoa's way".
Upon further investigation, I don't think this is a bug. I missed a part in the description: sevctl ok returns 1 on SNP capable Milan and Genoa when host kernel doesn't support SNP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In historical sevctl instances, ONLY the processor capabilities were checked for SEV-SNP support. In our latest release, we also check /dev/cpu/0/msr to check if SEV-SNP is enabled by the kernel, as well as in the CPU. Before, sevctl checked for processor capability to run SEV-SNP. Now, sevctl checks the overall system (firmware, kernel, etc). I think the MSR check is where sevctl is failing on Genoa. https://github.com/virtee/sevctl/blob/c41c9172be013d6f10b9e1d7286fcb021805d5a5/src/ok.rs#L279-L289 Zixi, can I have SSH access to the Genoa machine to test this?
(In reply to Tyler Fanelli from comment #2) > Upon further investigation, I don't think this is a bug. I missed a part in > the description: > > sevctl ok returns 1 on SNP capable Milan and Genoa when host kernel doesn't > support SNP > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > In historical sevctl instances, ONLY the processor capabilities were checked > for SEV-SNP support. In our latest release, we also check /dev/cpu/0/msr to > check if SEV-SNP is enabled by the kernel, as well as in the CPU. Before, > sevctl checked for processor capability to run SEV-SNP. Now, sevctl checks > the overall system (firmware, kernel, etc). I think the MSR check is where > sevctl is failing on Genoa. > > https://github.com/virtee/sevctl/blob/ > c41c9172be013d6f10b9e1d7286fcb021805d5a5/src/ok.rs#L279-L289 > > Zixi, can I have SSH access to the Genoa machine to test this? Sure, I just came back from PTO, you can have a test on my testing Genoa. By the way, could you please also check if this bug https://bugzilla.redhat.com/show_bug.cgi?id=2214839 affects sevctl ok info on Milan: [ PASS ] - Physical address bit reduction: 5 and Genoa [ PASS ] - Physical address bit reduction: 6?