Re: [patch V2 23/30] x86/fpu: Move fpregs_restore_userregs() to core

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 15, 2021 at 03:16:30AM +0200, Thomas Gleixner wrote:
> +static inline void fpregs_deactivate(struct fpu *fpu)
> +{
> +	__this_cpu_write(fpu_fpregs_owner_ctx, NULL);
> +	trace_x86_fpu_regs_deactivated(fpu);
> +}
> +
> +static inline void fpregs_activate(struct fpu *fpu)
> +{
> +	__this_cpu_write(fpu_fpregs_owner_ctx, fpu);
> +	trace_x86_fpu_regs_activated(fpu);

You're silently changing here the percpu writes to the __ variants and
AFAICT, there's no difference on x86:

# arch/x86/kernel/fpu/context.h:50: 	this_cpu_write(fpu_fpregs_owner_ctx, fpu);
#APP
# 50 "arch/x86/kernel/fpu/context.h" 1
	movq %rsi, %gs:fpu_fpregs_owner_ctx(%rip)	# fpu, fpu_fpregs_owner_ctx
# 0 "" 2

VS

# arch/x86/kernel/fpu/context.h:50: 	__this_cpu_write(fpu_fpregs_owner_ctx, fpu);
#APP
# 50 "arch/x86/kernel/fpu/context.h" 1
	movq %rsi, %gs:fpu_fpregs_owner_ctx(%rip)	# fpu, fpu_fpregs_owner_ctx
# 0 "" 2

except maybe the __ variant doesn't use the "volatile" inline asm
qualifier in the lower-level raw_cpu_write_8() vs this_cpu_write_8().
And there's the preemption check, ofc.

Or maybe this could have something to do with RT...?

Commit message could mention this change, though.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux