On 9/23/21 1:39 PM, Dr. David Alan Gilbert wrote:
* Brijesh Singh (brijesh.singh@amd.com) wrote:
quoted
On 9/22/21 1:55 PM, Dr. David Alan Gilbert wrote:
quoted
* Brijesh Singh (brijesh.singh@amd.com) wrote:
quoted
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.
quoted
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