On Tue, Dec 15, 2015 at 05:30:49PM -0800, Tony Luck wrote: > Using __copy_user_nocache() as inspiration create a memory copy > routine for use by kernel code with annotations to allow for > recovery from machine checks. > > Notes: > 1) We align the source address rather than the destination. This > means we never have to deal with a memory read that spans two > cache lines ... so we can provide a precise indication of > where the error occurred without having to re-execute at > a byte-by-byte level to find the exact spot like the original > did. > 2) We 'or' BIT(63) into the return because this is the first > in a series of machine check safe functions. Some will copy > from user addresses, so may need to indicate an invalid user > address instead of a machine check. > 3) This code doesn't play any cache games. Future functions can > use non-temporal loads/stores to meet needs of different callers. > 4) Provide helpful macros to decode the return value. > > Signed-off-by: Tony Luck <tony.l...@intel.com> > --- > arch/x86/include/asm/string_64.h | 8 +++ > arch/x86/kernel/x8664_ksyms_64.c | 4 ++ > arch/x86/lib/memcpy_64.S | 133 > +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 145 insertions(+)
... > + lea (%rdx,%rcx,8),%rdx > + jmp 100f > +40: > + mov %ecx,%edx > +100: > + sfence > + mov %edx,%eax > + bts $63,%rax > + ret Huh, bit 63 is still alive? Didn't we just talk about having different return values depending on whether a fault or an MCE happened *instead* of setting that bit? You have two "RET" points in that function, why not return a different value from each? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/