On 2019-04-12 18:48:28 [+0200], Borislav Petkov wrote:
> On Fri, Apr 12, 2019 at 06:37:41PM +0200, Sebastian Andrzej Siewior wrote:
> > (as you mentioned) so we would always record both trace points.
> > Therefore I would suggest to remove it.
>
> Remove which one?
remove x86_fpu_activate_state.
> Recording both TPs seems to make sense unless it doesn't make a whole
> lotta sense to have:
>
> fpregs_mark_activate
> |-> trace_x86_fpu_activate_state <-- TP1
> |-> fpregs_activate
> |-> trace_x86_fpu_regs_activated <-- TP2
> Yeah, looks like the two are too much and too close for no good
> reason. There's nothing particularly spectacular in-between in
> fpregs_activate().
correct.
> > Maybe we could add a new one to __fpregs_load_activate() one in case we
> > avoid loading registers because of fpregs_state_valid(). This might make
> > sense.
>
> But that's only the switch_fpu_return() path. Is fpregs_mark_activate()
> is going to use only the trace_x86_fpu_regs_activated() one? Note the
> "d" at the end.
You could have a trace-point in case we return to userland and we don't
load FPU registers because it looks like they are valid.
It was just an idea.
We could also rip all trcepoints out, rethink the situation and add new
ones based on current code.
- on schedule out, we may need to save registers (depending on
TIF_NEED_FPU_LOAD) which is new. Before the series we always did.
- on schedule in do nothing but set that TIF bit. This is probably
boring.
- on return to userland we should load the registers but can avoid it if
we assume that they are valid for the current task
(fpregs_state_valid())
- in kernel_fpu_begin() we may trash the task's FPU state (by saving its
registers or by resetting fpu_fpregs_owner_ctx).
Those might be interesting.
Currently we have:
"x86/fpu: %p load: %d xfeatures: %llx xcomp_bv: %llx"
and we have to find out what happens based on where that TP was
recorded. Also I'm not sure if the recorded xfeatures change over time.
I think they do not…
> [ Btw, those two names need adjusting too: who came up with such close,
> confusing names?!
> ]
you mean trace_x86_fpu_activate_state and trace_x86_fpu_regs_activated?
They were added in d1898b733619b ("x86/fpu: Add tracepoints to dump FPU
state at key points") and we wouldn't have any otherwise.
Sebastian
