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

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

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.

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

Does applying v2 of my patch corrects the picture?

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

Jan

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