[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH SpectreV1+L1TF v4 03/11] config: introduce L1TF_LFENCE option

>>> On 25.01.19 at 11:50, <nmanthey@xxxxxxxxx> wrote:
> On 1/25/19 11:14, Jan Beulich wrote:
>>>>> On 24.01.19 at 22:29, <andrew.cooper3@xxxxxxxxxx> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.