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.
> 
> 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. Then lets apply your patch for VMX with a comment that
explains why we need to save instruction length here (int3 will be
reinjected from userspace).

--
			Gleb.