Re: [PATCH v10 2/6] x86/sev: Initialize RMPOPT configuration MSRs
K Prateek Nayak <[email protected]>
| Newsgroups | dev.linux.lists.linux-coco,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hello Ashish,
On 7/21/2026 7:56 PM, Kalra, Ashish wrote:
> That's why v7 moved to a runtime check. In v11 (as i mentioned) this will be a small local helper, it will also handles two things
> the cap-clear can't:
> - a contiguous (non-segmented) RMP, where RMPOPT isn't usable even with X86_FEATURE_RMPOPT set.
> - SNP being disabled at runtime (CC_ATTR_HOST_SEV_SNP).
>
> static bool rmpopt_capable(void)
> {
> return cpu_feature_enabled(X86_FEATURE_RMPOPT) &&
> cc_platform_has(CC_ATTR_HOST_SEV_SNP) &&
CC_ATTR_HOST_SEV_SNP is set from bsp_determine_snp() ...
> (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) &&
... and that already checks snp_probe_rmptable_info() ...
> rmp_segment_table;
.. and if iommu_snp_enable() fails snp_rmptable_init(), we clear
CC_ATTR_HOST_SEV_SNP.
So, the way I see it, CC_ATTR_HOST_SEV_SNP being set means we have
already tried provisioning RMP table.
I'm assuming all platforms that have X86_FEATURE_RMPOPT will all have
segmented RMP. If not, you can just clear X86_FEATURE_RMPOPT in
snp_rmptable_init() no?
We can never reach functions that need rmpopt_capable() without
first checking CC_ATTR_HOST_SEV_SNP.
--
Thanks and Regards,
Prateek