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

[Xin Li <xin@zytor.com>]

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