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