On 9/23/21 1:39 PM, Dr. David Alan Gilbert wrote: > * Brijesh Singh (brijesh.singh@xxxxxxx) wrote: >> On 9/22/21 1:55 PM, Dr. David Alan Gilbert wrote: >>> * Brijesh Singh (brijesh.singh@xxxxxxx) wrote: >>>> Implement a workaround for an SNP erratum where the CPU will incorrectly >>>> signal an RMP violation #PF if a hugepage (2mb or 1gb) collides with the >>>> RMP entry of a VMCB, VMSA or AVIC backing page. >>>> >>>> When SEV-SNP is globally enabled, the CPU marks the VMCB, VMSA, and AVIC >>>> backing pages as "in-use" in the RMP after a successful VMRUN. This is >>>> done for _all_ VMs, not just SNP-Active VMs. >>> Can you explain what 'globally enabled' means? >> This means that SNP is enabled in host SYSCFG_MSR.Snp=1. Once its >> enabled then RMP checks are enforced. >> >> >>> Or more specifically, can we trip this bug on public hardware that has >>> the SNP enabled in the bios, but no SNP init in the host OS? >> Enabling the SNP support on host is 3 step process: >> >> step1 (bios): reserve memory for the RMP table. >> >> step2 (host): initialize the RMP table memory, set the SYSCFG msr to >> enable the SNP feature >> >> step3 (host): call the SNP_INIT to initialize the SNP firmware (this is >> needed only if you ever plan to launch SNP guest from this host). >> >> The "SNP globally enabled" means the step 1 to 2. The RMP checks are >> enforced as soon as step 2 is completed. > So I think that means we don't need to backport this to older kernels > that don't know about SNP but might run on SNP enabled hardware (1), since > those kernels won't do step2. Correct. thanks
