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

[Gleb Natapov <gleb@redhat.com>]

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. 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.

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

> 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.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux

--
			Gleb.