Messages in this thread | | | Date | Sat, 24 Jan 2015 12:14:30 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH v2 0/2] add support for new persistent memory instructions |
| |
On Fri, Jan 23, 2015 at 03:03:41PM -0800, H. Peter Anvin wrote: > For the specific case of CLWB, we can use an "m" input rather than a > "+m" output, simply because CLWB (or CLFLUSH* used as a standin for CLWB > doesn't need to be ordered with respect to loads (whereas CLFLUSH* do).
Well, we could do something like:
volatile struct { char x[64]; } *p = __p;
if (static_cpu_has(X86_FEATURE_CLWB)) asm volatile(".byte 0x66,0x0f,0xae,0x30" :: "m" (*p), "a" (p)); else asm volatile(ALTERNATIVE( ".byte 0x3e; clflush (%[pax])", ".byte 0x66; clflush (%[pax])", /* clflushopt (%%rax) */ X86_FEATURE_CLFLUSHOPT) : [p] "+m" (*p) : [pax] "a" (p));
which would simplify the alternative macro too.
Generated asm looks ok to me (my objdump doesn't know CLWB yet :)):
0000000000000aa0 <myclflush>: aa0: 55 push %rbp aa1: 48 89 e5 mov %rsp,%rbp aa4: eb 0a jmp ab0 <myclflush+0x10> aa6: 48 89 f8 mov %rdi,%rax aa9: 66 0f ae 30 data16 xsaveopt (%rax) aad: 5d pop %rbp aae: c3 retq aaf: 90 nop ab0: 48 89 f8 mov %rdi,%rax ab3: 3e 0f ae 38 clflush %ds:(%rax) ab7: 5d pop %rbp ab8: c3 retq
> Should we use an SFENCE as a standin if pcommit is unavailable, in case > we end up using CLFLUSHOPT?
Btw, is PCOMMIT a lightweight SFENCE for this persistent memory aspect to make sure stuff has become persistent after executing it? But not all stuff like SFENCE so SFENCE is the bigger hammer?
-- Regards/Gruss, Boris.
ECO tip #101: Trim your mails when you reply. --
| |