Re: [PATCH v1 2/4] x86/fred: Write to FRED MSRs with wrmsrns()

Xin Li
2024-07-04T00:20:57Z

On 7/3/2024 9:43 AM, Dave Hansen wrote:
> On 7/3/24 09:06, H. Peter Anvin wrote:
>> I believe tglx declared to use them unconditionally since FRED> depends on WRMSRNS (and the kernel enforces that.)
>
> Ahh, I forgot about:
>
> static const struct cpuid_dep cpuid_deps[] = {
> ...
> { X86_FEATURE_FRED, X86_FEATURE_WRMSRNS },
>
> So, yeah, Xin's patch here is quite safe and when Boris said:
>
>> Also, all those wrmsrns() writes better be behind a CPUID check.
>
> ... it *is* behind a CPUID check, but it's an implicit one.
>

Right!

Otherwise typically there will be two feature checks in a line in the
source code (the run time code is binary patched):

if (cpu_feature_enabled(X86_FEATURE_FRED)) {
if (cpu_feature_enabled(X86_FEATURE_WRMSRNS))
wrmsrns(MSR_IA32_FRED_RSP0, ...);
else
wrmsrl(MSR_IA32_FRED_RSP0, ...);
}

Yes, Andrew's idea to use alternative_input() is a clean approach that
everyone has agreed. However there is a more fundamental problem with
how WRMSR instruction is being used in the existing code:
https://lore.kernel.org/lkml/87y1h81ht4.ffs@tglx/.

My rough understanding is that first we want something like:
alternative_input("call paravirt_write_msr", "wrmsr", X86_FEATURE_XENPV);
to get PVOPS out of the picture, and then apply alternative_input() as
Andrew proposed.

I thought about giving it a shot, but it never comes to the top of my
task list.

Thanks!
Xin