On Tue, Sep 20, 2022 at 11:20:47AM +0300, Maxim Levitsky wrote:
> If I understand that correctly, the difference between clear_cpu_cap and setup_clear_cpu_cap
> is that setup_clear_cpu_cap should be called early when only the boot cpu is running and it
>
> 1. works on 'boot_cpu_data' which represents the boot cpu.
> 2. sets a bit in 'cpu_caps_cleared' which are later applied to all CPUs, including these that are hotplugged.
Yes.
> On the other hand the clear_cpu_cap just affects the given 'struct cpuinfo_x86'.
Yes.
> Call of 'clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR)' is weird since it still affects 'boot_cpu_data'
> but doesn't affect 'cpu_caps_cleared'
Yes.
> I assumed that this was a mistake and the intention was to disable the feature on all CPUs.
peterz says yes.
> I need this patch because in the next patch, I change the clear_cpu_cap such as it detects being
> called on boot_cpu_data and in this case also clears bits in 'cpu_caps_cleared', thus
> while this patch does introduce a functional change, the next patch doesn't since this is the only
> place where clear_cpu_cap is called explicitly on 'boot_cpu_data'
This is not needed - this patch doing setup_clear_cpu_cap() should suffice.
But, there must be something you're fixing with this. Which is it? Some
weird virt config?
> I do now notice that initcalls are run after smp is initialized, which
> means that this code doesn't really disable the CPUID feature on all
> CPUs at all.
Well, not exactly. There's do_pre_smp_calls() which is where the
early_initcall() thing is run.
So setup_clear_cpu_cap() will make sure that the feature bit is cleared
when the APs come online.
Do you have a virt configuration where you can test this case where the
feature flag is clear on all CPUs when it fails?
I.e., "arch_lbr" will disappear in /proc/cpuinfo completely.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
