Re: [PATCH 3/3] x86, FPU: Do not use static_cpu_has before alternatives

[Borislav Petkov <bp@alien8.de>]

On Mon, Apr 29, 2013 at 08:42:30AM -0700, H. Peter Anvin wrote:
> I *was* considering adding static_cpu_has_safe() at some point which
> would have a three-state jump, with the default (pre-alternatives)
> jump pointing to dynamic detection code.

Actually, if we teach __static_cpu_has to do something like
ALTERNATIVE_JUMP arch/x86/lib/copy_user_64.S but make the second
alternative insn alt2 be none, i.e. no replacement, we can have:

* pre-alternatives: JMP dynamic_detection
* post-alternatives:
  - feature present: delete JMP
  - feature absent: s/dynamic_detection/t_no/, i.e., patch only the label.

And even though asm goto supports multiple labels, we need to be able
to either patch the label only or patch out the whole instruction -
otherwise we'll be adding additional NOP bytes.

I wonder if it would make sense to teach the alternatives to skip the
opcode when patching so that we can say: "we only want to patch the
label so we're patching in the offset now but leaving the single JMP
opcode in there."

But for that we either need flags in struct alt_instr or do something
ad-hoc apply_alternatives already does for relative jumps (0xe8).

> This might be useful here, on the other hand, perhaps it is acceptable
> for use_eager_fpu() to be initially false?

Hmm, I don't know, FPU code is crazy. OTOH, does CR0.TS even matter on
non-lazy FPU restore machines?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--