Re: [PATCH v7 2/6] x86/sev: Initialize RMPOPT configuration MSRs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling `setup_clear_cpu_cap()` during initcalls triggers an unconditional kernel `WARN_ON` trace because CPU alternatives have already been patched.
--

commit 155a667bf78d513dde1064d7dae284cc80a5dcba
Author: Ashish Kalra <ashish.kalra@amd.com>

x86/sev: Initialize RMPOPT configuration MSRs

The new RMPOPT instruction helps manage per-CPU RMP optimization
structures inside the CPU. It takes a 1GB-aligned physical address
and either returns the status of the optimizations or tries to enable
the optimizations.

> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
> index 989ca9f72ba30..a8fc2ae502985 100644
> --- a/arch/x86/coco/core.c
> +++ b/arch/x86/coco/core.c
> @@ -172,6 +173,8 @@ static void amd_cc_platform_clear(enum cc_attr attr)
>  	switch (attr) {
>  	case CC_ATTR_HOST_SEV_SNP:
>  		cc_flags.host_sev_snp = 0;
> +		snp_clear_rmpopt_configured();
> +		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);

[Severity: High]
Does this code trigger a WARN_ON() stack trace?

The function setup_clear_cpu_cap() has an explicit WARN_ON(alternatives_patched).
This path can be executed from initcalls long after arch_cpu_finalize_init()
has set alternatives_patched to 1.

>  		break;
>  	default:
>  		break;

[ ... ]

> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index 8bcdce98f6dce..482008bb07e48 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c

[ ... ]

> @@ -488,9 +492,14 @@ static bool __init setup_segmented_rmptable(void)
>  static bool __init setup_rmptable(void)
>  {
>  	if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
> -		if (!setup_segmented_rmptable())
> +		if (!setup_segmented_rmptable()) {
> +			setup_clear_cpu_cap(X86_FEATURE_RMPOPT);

[Severity: High]
Can this also trigger the same alternatives_patched WARN_ON() trace?

Since setup_rmptable() can run as part of rootfs_initcalls (via pci_iommu_init()
and amd_iommu_init()), alternatives will already be patched by the time this runs.

>  			return false;
> +		}
> +		rmpopt_configured = true;
>  	} else {
> +		/* Note that Segmented RMP must be enabled to enable RMPOPT. */
> +		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);

[Severity: High]
Would this also result in a WARN_ON() during boot if the system supports RMPOPT
but segmented RMP is disabled?

>  		if (!setup_contiguous_rmptable())
>  			return false;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1780903370.git.ashish.kalra@amd.com?part=2