On Wed, Feb 17, 2010 at 04:13:11PM +0100, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Wed, Feb 17, 2010 at 12:32:05PM +0100, Jan Kiszka wrote: > >> Gleb Natapov wrote: > >>> On Mon, Feb 15, 2010 at 02:20:31PM +0100, Jan Kiszka wrote: > >>>> Jan Kiszka wrote: > >>>>> Gleb Natapov wrote: > >>>>>> Lets check if SVM works. I can do that if you tell me how. > >>>>> - Fire up some Linux guest with gdb installed > >>>>> - Attach gdb to gdbstub of the VM > >>>>> - Set a soft breakpoint in guest kernel, ideally where it does not > >>>>> immediately trigger, e.g. on sys_reboot (use grep sys_reboot > >>>>> /proc/kallsyms if you don't have symbols for the guest kernel) > >>>>> - Start gdb /bin/true in the guest > >>>>> - run > >>>>> > >>>>> As gdb sets some automatic breakpoints, this already exercises the > >>>>> reinjection of #BP. > >>>> I just did this on our primary AMD platform (Embedded Opteron, 13KS EE), > >>>> and it just worked. > >>>> > >>> I tested it on processor without NextRIP and your test case works there > >>> too, > >>> but it shouldn't have, so I looked deeper into that and what I see is > >>> that GDB outsmart us. It doesn't matter if we inject event before int3 > >>> inserted by GDB or after it GDB correctly finds breakpoint that > >>> triggered and restart instruction correctly. I assume it doesn't use > >>> exact match between rip where int3 was inserted and where exceptions > >>> triggers. > >> At latest when you have two successive breakpoints on single-byte > >> instructions, gdb will reach its limits (for it failed earlier, BTW). > >> And other debuggers under other OSes may become unhappy as well. > > Yes, and that is why I am saying checking with GDB is not a good test. > > GDB may work, but it doesn't mean injection works correctly. It took me > > some time to write test that finally confused gdb. It was like this: > > > > 1: int main(int argc, char **argv) > > 2: { > > 3: if (argc == 1) > > 4: goto a; > > 5: asm("cmc"); > > 6: a: > > 7: asm("cmc"); > > 8: return 0; > > 9: } > > > > If you set breakpoint on lines 5 and 7 when breakpoint triggers GDB > > thinks it is on line 5. > > > > So can you run int3 test below on master on AMD with NextRIP support? > > I doubt the result will be correct. > > If you meant your test above: Works out of the box with unpatched kvm on > modern AMD CPUs, ie. gdb always stops at line 7 even if host debugging > is active. > I meant test that does asm("int3") and see that rip it reports with and without host debugging active is the same and points after int3. But I guess if program above works correctly int3 test should work too. Thanks.
-- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html