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

[Jan Kiszka <jan.kiszka@siemens.com>]

Gleb Natapov wrote:
> 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.

If you meant your test above: Works out of the box with unpatched kvm on
modern AMD CPUs, ie. gdb always stops at line 7 even if host debugging
is active.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux