On 2/25/25 11:45, Pratik R. Sampat wrote: > On 2/25/2025 10:41 AM, Pratik R. Sampat wrote: >> Hi Tom, >> >> On 2/24/2025 3:28 PM, Tom Lendacky wrote: >>> On 2/21/25 15:01, Pratik R. Sampat wrote: >>>> During platform init, SNP initialization may fail for several reasons, >>>> such as firmware command failures and incompatible versions. However, >>>> the KVM capability may continue to advertise support for it. Export this >>>> information to KVM and withdraw SEV-SNP support if has not been >>>> successfully initialized. >>> >>> Hmmm... rather than creating a new API, can you just issue an >>> SNP_PLATFORM_STATUS command and see if the SNP is not in the UNINIT state? >>> >> >> Although reading sev->snp_initialized is probably cheaper to do, it is >> cleaner to query the platform status. >> >> Querying SNP_PLATFORM_STATUS requires the pages to transition to >> firmware-owned and back, and the helpers for it are implemented within >> sev-dev.c. So, similar to sev_platform_status(), I'm thinking it is >> probably better to create the snp_platform_status() API as well and use >> that within KVM to check the state. >> > > Although I am guessing the initial intent was to not have an API exposed > at all from CCP and only make the SNP_PLATFORM_STATUS call instead? > > Since that may not be cleanly possible (we have helpers for page state > conversions such as rmp_mark_pages_firmware() in ccp) without > duplicating functionality in KVM as well, I guess the question really > boils down to whether we export the cheaper snp_initialized() or the > snp_platform_status() API instead? Taking a closer look, we do already have APIs that KVM uses to allocate firmware pages (output pages for SNP APIs) that can be used: snp_alloc_firmware_page() and snp_free_firmware_page(). I think that should be enough to use sev_do_cmd() to perform the SEV_CMD_SNP_PLATFORM_STATUS command without exposing a new API. Thanks, Tom > > Thanks again! > Pratik
