From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v3 4/9] target-i386: Add infrastructure for reporting TPR MMIO accesses Date: Thu, 16 Feb 2012 16:29:07 +0100 Message-ID: <4F3D20C3.3040408@siemens.com> References: <3ac2ae28b19aabebd3937b87ff365b481f990779.1329232393.git.jan.kiszka@siemens.com> <4F3D1F11.5070804@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Gleb Natapov , "kvm@vger.kernel.org" , Marcelo Tosatti , qemu-devel , Blue Swirl To: Avi Kivity Return-path: In-Reply-To: <4F3D1F11.5070804@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 2012-02-16 16:21, Avi Kivity wrote: > On 02/14/2012 05:13 PM, Jan Kiszka wrote: >> Note that KVM without in-kernel irqchip will report the address after >> the instruction that triggered a write access. In contrast, read >> accesses will return the precise information. >> > > Well this is wierd. We could retro-doc one or the other behaviour, but > this-on-read-but-that-on-write is just too strange. > > The documented way of dealing with this is to queue a signal and reenter > the guest. kvm will perform anything it needs to complete the > instruction (perhaps issuing more mmio, say if someone used movsd to > read the APIC) and then exit on the signal. By then rip will point > exactly after the instruction. Hmm, true. And can trivially be changed (I'm injecting the event after instruction completion). Will role out a new version. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ry3Gm-0005WS-LL for qemu-devel@nongnu.org; Thu, 16 Feb 2012 10:29:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ry3Gi-0002Un-Lj for qemu-devel@nongnu.org; Thu, 16 Feb 2012 10:29:16 -0500 Received: from thoth.sbs.de ([192.35.17.2]:33880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ry3Gi-0002Uc-2n for qemu-devel@nongnu.org; Thu, 16 Feb 2012 10:29:12 -0500 Message-ID: <4F3D20C3.3040408@siemens.com> Date: Thu, 16 Feb 2012 16:29:07 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <3ac2ae28b19aabebd3937b87ff365b481f990779.1329232393.git.jan.kiszka@siemens.com> <4F3D1F11.5070804@redhat.com> In-Reply-To: <4F3D1F11.5070804@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 4/9] target-i386: Add infrastructure for reporting TPR MMIO accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Gleb Natapov , "kvm@vger.kernel.org" , Marcelo Tosatti , qemu-devel , Blue Swirl On 2012-02-16 16:21, Avi Kivity wrote: > On 02/14/2012 05:13 PM, Jan Kiszka wrote: >> Note that KVM without in-kernel irqchip will report the address after >> the instruction that triggered a write access. In contrast, read >> accesses will return the precise information. >> > > Well this is wierd. We could retro-doc one or the other behaviour, but > this-on-read-but-that-on-write is just too strange. > > The documented way of dealing with this is to queue a signal and reenter > the guest. kvm will perform anything it needs to complete the > instruction (perhaps issuing more mmio, say if someone used movsd to > read the APIC) and then exit on the signal. By then rip will point > exactly after the instruction. Hmm, true. And can trivially be changed (I'm injecting the event after instruction completion). Will role out a new version. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux