From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH] KVM: VMX: Update instruction length on intercepted BP Date: Wed, 17 Feb 2010 14:39:39 +0200 Message-ID: <20100217123939.GT2995@redhat.com> References: <4B7826D3.7080201@web.de> <20100214165319.GA19246@redhat.com> <4B782D97.9030304@web.de> <20100214172613.GB19246@redhat.com> <4B7837A3.4040607@web.de> <4B794A1F.7050009@siemens.com> <20100215133042.GC19478@redhat.com> <4B7BCEE8.8040708@redhat.com> <20100217111327.GR2995@redhat.com> <4B7BD1E3.2050709@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:26255 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757192Ab0BQMjn (ORCPT ); Wed, 17 Feb 2010 07:39:43 -0500 Content-Disposition: inline In-Reply-To: <4B7BD1E3.2050709@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Feb 17, 2010 at 12:24:19PM +0100, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Wed, Feb 17, 2010 at 01:11:36PM +0200, Avi Kivity wrote: > >> On 02/15/2010 03:30 PM, Gleb Natapov wrote: > >>>> 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. > >> How much older are they? > >> > > Actually I am not sure new AMDs support this correctly. Need one to run > > tests. GDB is not a good test case, it is too smart. > > It works well - and gdb is far from being "smart": one byte off the > expected INT3 address, and everything falls apart. That's what the VMX > bug demonstrated. > Simple test on AMD shows the one byte off doesn't matter for GDB, at least as long as this byte still belong to the same instruction or may be same line of source code. On VMX something else happens. I can't reproduce problem on master with VMX since event_exit_inst_len is always 1 when #DB is reinjected. May be in your test we are much more then 1 byte off on VMX? -- Gleb.