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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
