[MODERATED] Re: [PATCH v5 09/11] TAAv5 9

> > +static void tsx_update_this_cpu(void *arg)
> > +{
> > +	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
> > +	unsigned long enable = (unsigned long)arg;
> > +
> > +	if (enable) {
> > +		tsx_enable();
> > +		set_cpu_cap(c, X86_FEATURE_RTM);
> > +		setup_force_cpu_cap(X86_FEATURE_RTM);
> > +	} else {
> > +		tsx_disable();
> > +		clear_cpu_cap(c, X86_FEATURE_RTM);
> > +		setup_clear_cpu_cap(X86_FEATURE_RTM);
> > +	}
> > +}
> 
> You can't use these setup_... functions after boot like this.  Also, I'm
> not sure you can safely even set_cpu_cap(...) after boot.

The only reason they are there is because guests started after changing
the TSX state from sysfs don't get the correct X86_FEATURE_RTM(with qemu
option "-cpu host") . Perhaps there needs to be a fix in qemu/KVM to
read the cpuid and export the correct X86_FEATURE_RTM bit.

> 
> > +
> > +static void tsx_update_on_each_cpu(bool val)
> > +{
> > +	get_online_cpus();
> > +	on_each_cpu(tsx_update_this_cpu, (void *)val, 1);
> > +	put_online_cpus();
> 
> I sure hope that on_each_cpu() is sensible enough to automatically do
> the get_online_cpus() thing.  Is it not?

I dont see cpu_hotplug_lock being taken by on_each_cpu(), which
get_online_cpus() does. This prevents cpus to go down/up when we are
writing to MSR.

Thanks,
Pawan