On Wed, Feb 17, 2010 at 12:24:19PM +0100, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Wed, Feb 17, 2010 at 01:11:36PM +0200, Avi Kivity wrote: > >> On 02/15/2010 03:30 PM, Gleb Natapov wrote: > >>>> I just did this on our primary AMD platform (Embedded Opteron, 13KS EE), > >>>> and it just worked. > >>>> > >>>> But this is a fairly new processor. Consequently, it reports NextRIP > >>>> support via cpuid function 0x8000000A. Looking for an older one too. > >>>> > >>>> In the meantime I also browsed a bit more in the manuals, and I don't > >>>> think stepping over or (what is actually required) into an INT3 will > >>>> work. We can't step into as the processor clears TF on any event handler > >>>> entry. And stepping over would cause troubles > >>>> > >>>> a) as an unknown amount of code may run without #DB interception > >>>> b) we would fiddle with TF in code that is already under debugger > >>>> control, thus we would very likely run into conflicts. > >>>> > >>>> Leaves us with tricky INT3 emulation. Sigh. > >>>> > >>> So the question is do we want to support this kind of debugging on older > >>> AMDs. May we don't. > >> How much older are they? > >> > > Actually I am not sure new AMDs support this correctly. Need one to run > > tests. GDB is not a good test case, it is too smart. > > It works well - and gdb is far from being "smart": one byte off the > expected INT3 address, and everything falls apart. That's what the VMX > bug demonstrated. > Simple test on AMD shows the one byte off doesn't matter for GDB, at least as long as this byte still belong to the same instruction or may be same line of source code. On VMX something else happens. I can't reproduce problem on master with VMX since event_exit_inst_len is always 1 when #DB is reinjected. May be in your test we are much more then 1 byte off on VMX? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
