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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
