Re: [PATCH] KVM: VMX: Update instruction length on intercepted BP

[Gleb Natapov <gleb@redhat.com>]

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.

> 
> > But if I run program below on latest kernel which prints rip
> > where #DB was delivered in dmesg I get different results with and
> > without external breakpoint inserted.
> 
> Does applying v2 of my patch corrects the picture?
> 
Of course, since it now injects #DB at correct address. If exception
will happen during #DB processing thins will go wrong, but we can do
only so much on broken SVM without emulating int3 in software.

> > 
> > int main(int argc, char **argv)
> > {
> >         asm("int3");
> >         return 0;
> > }
> > 

--
			Gleb.