From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: VMX: Update instruction length on intercepted BP Date: Wed, 17 Feb 2010 12:32:05 +0100 Message-ID: <4B7BD3B5.2080207@siemens.com> References: <4B77D4DE.3030602@web.de> <20100214111544.GJ2511@redhat.com> <4B77E0E2.7030704@web.de> <20100214144501.GN2511@redhat.com> <4B7826D3.7080201@web.de> <20100214165319.GA19246@redhat.com> <4B782D97.9030304@web.de> <20100214172613.GB19246@redhat.com> <4B7837A3.4040607@web.de> <4B794A1F.7050009@siemens.com> <20100217105527.GQ2995@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Marcelo Tosatti , kvm To: Gleb Natapov Return-path: Received: from thoth.sbs.de ([192.35.17.2]:16393 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752223Ab0BQLcZ (ORCPT ); Wed, 17 Feb 2010 06:32:25 -0500 In-Reply-To: <20100217105527.GQ2995@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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