[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170317035716-mutt-send-email-mst@kernel.org>
Date: Fri, 17 Mar 2017 04:03:59 +0200
From: "Michael S. Tsirkin" <mst@...hat.com>
To: "Gabriel L. Somlo" <gsomlo@...il.com>
Cc: Radim Krčmář <rkrcmar@...hat.com>,
linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Jonathan Corbet <corbet@....net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests
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
Powered by blists - more mailing lists