On 1/28/19 08:35, Jan Beulich wrote: >>>> On 27.01.19 at 21:28, <nmant...@amazon.de> wrote: >> 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. > But didn't you say earlier that there was no difference in generated > code between the two variants?
Yes, for the current commit, and for the 1 compiler I used. Personally, I prefer the logic operand variant. You seem to prefer the ternary variant, and Andrew at least raised concerns there. I would really like to move forward somehow, but currently it does not look really clear how to achieve that. I try to apply majority vote for each hunk that has been commented and create a v5 of the series. I even think about separating the introduction of eval_nospec and the arch_nospec_barrier macro into another series to move faster with the array_index_nospec-based changes first. Guidance is very welcome. 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
