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
