On 03/16, Borislav Petkov wrote:
>
> On Sun, Mar 15, 2015 at 05:49:48PM +0100, Oleg Nesterov wrote:
> >
> > And I agree with Quentin, user_insn/check_insn can be improved to allow
> > clobbers, more flexible "output", etc. But imo they already can make this
> > code look a bit better, and "xstate_fault" must die eventually.
>
> FWIW, I did poke at that but there's still something wrong with my macros, 
> will
> take a look when I get a chance:

Sure, I won't argue if we use the new macros instead. But we already have
check_insn/user_insn, why not use them?

For example,

> +#define XSTATE_XSAVE(st, lmask, hmask, err)                          \
> +     asm volatile(ALTERNATIVE_2(XSAVE,                               \
> +                                XSAVEOPT, X86_FEATURE_XSAVEOPT,      \
> +                                XSAVES,   X86_FEATURE_XSAVES)        \
> +                  "\n"                                               \
> +                  ".pushsection .fixup,\"ax\"\n"                     \
> +                  "3: movl $-1, %[err]\n"                            \
> +                  "jmp " alt_end_marker "b\n"                        \
> +                  ".popsection\n"                                    \
> +                  _ASM_EXTABLE(661b, 3b)                             \
> +                  : [err] "=r" (err)                                 \
> +                  : "D" (st), "a" (lmask), "d" (hmask)               \
> +                  : "memory")
> +

to me check_insn(ALTERNATIVE_2(...)) looks better. Except we need the
clobber. It is not easy to read the code like this, imo it would be better
to avoid copy-and-paste and use the helpers we already have. Just we need
to improve them.


But let me repeat, I leave this to you and others, I do not understand
asm enough.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to