From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alGCm-0007tq-MZ for qemu-devel@nongnu.org; Wed, 30 Mar 2016 09:30:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alGCg-0003hQ-VI for qemu-devel@nongnu.org; Wed, 30 Mar 2016 09:30:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alGCg-0003hI-IW for qemu-devel@nongnu.org; Wed, 30 Mar 2016 09:30:34 -0400 References: <1459263745-1035-1-git-send-email-rjones@redhat.com> From: Paolo Bonzini Message-ID: <56FBD4F6.7050904@redhat.com> Date: Wed, 30 Mar 2016 15:30:30 +0200 MIME-Version: 1.0 In-Reply-To: <1459263745-1035-1-git-send-email-rjones@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] exec: Rename and fix trace events for tracing I/O port access. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" , qemu-devel@nongnu.org Cc: crosthwaite.peter@gmail.com, stefanha@redhat.com, rth@twiddle.net On 29/03/2016 17:02, Richard W.M. Jones wrote: > Back in the day you used to be able to set DEBUG_IOPORT in ioport.c > and get qemu to dump what (x86) I/O ports were being accessed by the > guest. This was rather useful for finding out what closed source > device drivers were up to. >=20 > Now you're supposed to use cpu_in/cpu_out tracepoints instead. > However for the majority of guests these tracepoints will never be > called. For what it's worth, the breakage dated to way before DEBUG_IOPORT was converted to tracepoints. (This is why putting tracing code behind #if 0 is bad). It happened when I/O ports stopped being special snowflakes, and started being just like any other MMIO target (except they live in another address space). > It turns out this is still not particularly useful for debugging > because (a) it creates massive amounts of log messages and (b) there's > no way to select a range of addresses or a device of interest. For > example, if you have a serial port, everything else gets swamped by > I/O access to the serial port. Am I wrong that this is not any better/worse than "-d ioport" used to be? > Maybe using a different tracing backend (eg. stap) would help? You are actually logging every memory write (except stuff that it's DMA'd from/to block devices directly by passing a guest memory pointer to preadv/pwritev). That's way more than just I/O ports. However I understand that it's useful to treat them as special snowflakes for the purpose of tracing. To fix the problem with your patch, I suggest to: - consolidate the six tracepoints in 2 (cpu_in and cpu_out) that take the size as an extra argument - keep the existing calls to the tracepoints, and add more calls in kvm_handle_io and in the helpers in target-i386/misc_helper.c. Paolo