Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752379AbdCQCEQ (ORCPT <rfc822;w@1wt.eu>);
        Thu, 16 Mar 2017 22:04:16 -0400
Received: from mx1.redhat.com ([209.132.183.28]:35006 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751062AbdCQCEM (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 16 Mar 2017 22:04:12 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C1D2F15561
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mst@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C1D2F15561
Date: Fri, 17 Mar 2017 04:03:59 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        x86@kernel.org, Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        linux-doc@vger.kernel.org
Subject: Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests
Message-ID: <20170317035716-mutt-send-email-mst@kernel.org>
References: <20170316153517.GL14081@potion>
 <20170316160157.GN14081@potion>
 <20170316164749.GG4085@HEDWIG.INI.CMU.EDU>
 <20170316192622-mutt-send-email-mst@kernel.org>
 <20170316174149.GK4085@HEDWIG.INI.CMU.EDU>
 <20170316202024-mutt-send-email-mst@kernel.org>
 <20170316192440.GL4085@HEDWIG.INI.CMU.EDU>
 <20170316212635-mutt-send-email-mst@kernel.org>
 <20170316201710.GN4085@HEDWIG.INI.CMU.EDU>
 <20170316211414.GO4085@HEDWIG.INI.CMU.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170316211414.GO4085@HEDWIG.INI.CMU.EDU>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 17 Mar 2017 02:04:03 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2851
Lines: 73

On Thu, Mar 16, 2017 at 05:14:15PM -0400, Gabriel L. Somlo wrote:
> On Thu, Mar 16, 2017 at 04:17:11PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote:
> > > > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote:
> > > > > Let's take a step back and try to figure out how is
> > > > > mwait called. How about dumping code of VCPUs
> > > > > around mwait?  gdb disa command will do this.
> > > > 
> > > > Started guest with '-s', tried to attach from gdb with
> > > > "target remote localhost:1234", got
> > > > "remote 'g' packet reply is too long: <lengthy string of numbers>"
> > > 
> > > Try
> > > 
> > > set arch x86-64:x86-64
> > 
> > 'set architecture i386:x86-64:intel' is what worked for me;
> > 
> > Been rooting around for a while, can't find mwait or monitor :(
> > 
> > Guess I'll have to recompile KVM to actually issue an invalid opcode,
> > so OS X will print a panic message with the exact address :)
> > 
> > Stay tuned...
> 
> OK, so I found a few instances. The one closest to where a random
> interrupt from gdb landed, was this one:
> 
> ...
>    0xffffff7f813ff379:  mov    0x90(%r15),%rax
>    0xffffff7f813ff380:  mov    0x18(%rax),%rsi
>    0xffffff7f813ff384:  xor    %ecx,%ecx
>    0xffffff7f813ff386:  mov    %rsi,%rax
>    0xffffff7f813ff389:  xor    %edx,%edx
>    0xffffff7f813ff38b:  monitor %rax,%rcx,%rdx
>    0xffffff7f813ff38e:  test   %r14,%r14
>    0xffffff7f813ff391:  je     0xffffff7f813ff3ad
>    0xffffff7f813ff393:  movq   $0x0,0x8(%r14)
>    0xffffff7f813ff39b:  movl   $0x0,(%r14)
>    0xffffff7f813ff3a2:  test   %ebx,%ebx
>    0xffffff7f813ff3a4:  je     0xffffff7f813ff3b2
>    0xffffff7f813ff3a6:  mfence 
>    0xffffff7f813ff3a9:  wbinvd
>    0xffffff7f813ff3ab:  jmp    0xffffff7f813ff3b2
>    0xffffff7f813ff3ad:  cmpl   $0x0,(%rsi)

Seems to do cmpl - could indicate it uses different bytes
for signalling? Radim's test monitors and
modifies the same byte...

>    0xffffff7f813ff3b0:  jne    0xffffff7f813ff3d6
>    0xffffff7f813ff3b2:  mov    %r12d,%eax
>    0xffffff7f813ff3b5:  imul   $0x148,%rax,%rax
>    0xffffff7f813ff3bc:  lea    0x153bd(%rip),%rcx        # 0xffffff7f81414780
>    0xffffff7f813ff3c3:  mov    (%rcx),%rcx 
>    0xffffff7f813ff3c6:  mov    0x20(%rcx),%rcx
>    0xffffff7f813ff3ca:  mov    0xc(%rcx,%rax,1),%eax
>    0xffffff7f813ff3ce:  mov    $0x1,%ecx
>    0xffffff7f813ff3d3:  mwait  %rax,%rcx
> => 0xffffff7f813ff3d6:  lfence
>    0xffffff7f813ff3d9:  rdtsc  
>    0xffffff7f813ff3db:  lfence 
>    0xffffff7f813ff3de:  mov    %rax,%rbx
>    0xffffff7f813ff3e1:  mov    %rdx,%r15
> ...

OK nice, so it's actually using 1 for ECX. Now what's rax?
Can you check that with gdb pls, then try that value with
Radim's test?

-- 
MST