>>> On 16.03.18 at 11:37, wrote:
> I think we should do some performance testing to decide whether it makes
> sense to take the patch or not. After all I don't see a reason to punish
> AMD processors for INTEL's bugs. And I've already found out that some
> branches in interrupt handling can really
On 16/03/18 10:46, Jan Beulich wrote:
On 15.03.18 at 20:44, wrote:
>> On 13/03/18 13:47, Jan Beulich wrote:
>>> Introduce a synthetic feature flag to use alternative instruction
>>> patching to NOP out all code on entry/exit paths. Having NOPs here is
>>> generally better than using condition
>>> On 15.03.18 at 20:44, wrote:
> On 13/03/18 13:47, Jan Beulich wrote:
>> Introduce a synthetic feature flag to use alternative instruction
>> patching to NOP out all code on entry/exit paths. Having NOPs here is
>> generally better than using conditional branches.
>>
>> Also change the limit on
On 15/03/18 20:44, Andrew Cooper wrote:
> On 13/03/18 13:47, Jan Beulich wrote:
>> Introduce a synthetic feature flag to use alternative instruction
>> patching to NOP out all code on entry/exit paths. Having NOPs here is
>> generally better than using conditional branches.
>>
>> Also change the li
On 13/03/18 13:47, Jan Beulich wrote:
> Introduce a synthetic feature flag to use alternative instruction
> patching to NOP out all code on entry/exit paths. Having NOPs here is
> generally better than using conditional branches.
>
> Also change the limit on the number of bytes we can patch in one
Introduce a synthetic feature flag to use alternative instruction
patching to NOP out all code on entry/exit paths. Having NOPs here is
generally better than using conditional branches.
Also change the limit on the number of bytes we can patch in one go to
that resulting from the encoding in struc
