On 1/25/19 14:09, Jan Beulich wrote: >>>> On 25.01.19 at 11:50, <nmant...@amazon.de> wrote: >> On 1/25/19 11:14, Jan Beulich wrote: >>>>>> On 24.01.19 at 22:29, <andrew.coop...@citrix.com> wrote: >>>> Worse is the "evaluate condition, stash result, fence, use variable" >>>> option, which is almost completely useless. If you work out the >>>> resulting instruction stream, you'll have a conditional expression >>>> calculated down into a register, then a fence, then a test register and >>>> conditional jump into one of two basic blocks. This takes the perf hit, >>>> and doesn't protect either of the basic blocks for speculative >>>> mis-execution. >>> How does it not protect anything? It shrinks the speculation window >>> to just the register test and conditional branch, which ought to be >>> far smaller than that behind a memory access which fails to hit any >>> of the caches (and perhaps even any of the TLBs). This is the more >>> that LFENCE does specifically not prevent insn fetching from >>> continuing. >>> >>> That said I agree that the LFENCE would better sit between the >>> register test and the conditional branch, but as we've said so many >>> times before - this can't be achieved without compiler support. It's >>> said enough that the default "cc" clobber of asm()-s on x86 alone >>> prevents this from possibly working, while my over four year old >>> patch to add a means to avoid this has not seen sufficient >>> comments to get it into some hopefully acceptable shape, but also >>> has not been approved as is. >>> >>> Then again, following an earlier reply of mine on another sub- >>> thread, nothing really prevents the compiler from moving ahead >>> and folding the two LFENCEs of the "both branches" model into >>> one. It just so happens that apparently right now this never >>> occurs (assuming Norbert has done full generated code analysis >>> to confirm the intended placement). >> I am happy to jump back to my earlier version without a configuration >> option to protect both branches with a lfence instruction, using logic >> operators. > I don't understand this, I'm afraid: What I've said was to support > my thinking of the && + || variant being identical in code and risk > to that using ?: . I.e. I'm not asking you to switch back.
I understand that you did not ask. However, Andrew raised concerns, and I analyzed the binary output for the variant with logical operators. Hence, I'd like to keep that variant with the logical operators. Best, Norbert > > Jan > > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
