Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] x86/TSC: Use RDTSCP
To:     Borislav Petkov <bp@alien8.de>
Cc:     X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        Andy Lutomirski <luto@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        John Stultz <john.stultz@linaro.org>,
        Thomas Lendacky <Thomas.Lendacky@amd.com>
References: <20181119184556.11479-1-bp@alien8.de>
 <20181123200307.GA6223@roeck-us.net> <20181123204425.GN30697@zn.tnic>
From:   Guenter Roeck <linux@roeck-us.net>
Message-ID: <901af2a0-e0d7-586d-5f04-2066cf1ac871@roeck-us.net>
Date:   Fri, 23 Nov 2018 13:03:25 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20181123204425.GN30697@zn.tnic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/23/18 12:44 PM, Borislav Petkov wrote:
> On Fri, Nov 23, 2018 at 12:03:07PM -0800, Guenter Roeck wrote:
>> [    0.762832] EIP: read_tsc+0x4/0x10
>> [    0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90 90 90 90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57 <0f> ae f0b
> 
> Where does that 'b' in f0b come from?
> 

Good catch.

It is a cut off screen log. x86 boots change xterm configuration from
wrap to non-wrap, and I did a cut-and-paste instead of copying the log
to a file. Sorry for that.

Guenter

> But ok, I was able to reproduce and decode myself. So if the Code:
> section is correct, qemu chokes on MFENCE.
> 
> [ 0.854209] Code: 90 90 90 90 90 90 90 a1 84 37 11 cd c3 8d b4 26 00 00 00 00 8d 76 00 c3 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 90 55 89 e5 <0f> ae f0 0f 31 5d c3 8d b6 00 00 00 00 55 89 e5 57 31 ff 56 53 89
> All code
> ========
>     0:   90                      nop
>     1:   90                      nop
>     2:   90                      nop
>     3:   90                      nop
>     4:   90                      nop
>     5:   90                      nop
>     6:   90                      nop
>     7:   a1 84 37 11 cd          mov    0xcd113784,%eax
>     c:   c3                      ret
>     d:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
>    14:   8d 76 00                lea    0x0(%esi),%esi
>    17:   c3                      ret
>    18:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
>    1f:   8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
>    26:   90                      nop
>    27:   55                      push   %ebp
>    28:   89 e5                   mov    %esp,%ebp
>    2a:*  0f ae f0                mfence          <-- trapping instruction
>    2d:   0f 31                   rdtsc
>    2f:   5d                      pop    %ebp
>    30:   c3                      ret
>    31:   8d b6 00 00 00 00       lea    0x0(%esi),%esi
>    37:   55                      push   %ebp
>    38:   89 e5                   mov    %esp,%ebp
>    3a:   57                      push   %edi
>    3b:   31 ff                   xor    %edi,%edi
>    3d:   56                      push   %esi
>    3e:   53                      push   %ebx
>    3f:   89                      .byte 0x89
> 
> Doing this:
> 
>          asm volatile(ALTERNATIVE_2("mfence", ...
> 
> fails too which confirms that P3 can't do MFENCE.
> 
> I need to think about how to handle that old cruft.
> 
> Thx for the report.
>