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:24:19 +0100 Message-ID: <4B7BD1E3.2050709@siemens.com> References: <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> <20100215133042.GC19478@redhat.com> <4B7BCEE8.8040708@redhat.com> <20100217111327.GR2995@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 goliath.siemens.de ([192.35.17.28]:23277 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752340Ab0BQLYj (ORCPT ); Wed, 17 Feb 2010 06:24:39 -0500 In-Reply-To: <20100217111327.GR2995@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux