Re: [Qemu-devel] [PATCH] exec: Rename and fix trace events for tracing I/O port access.

[Daniel P. Berrange]

On Tue, Mar 29, 2016 at 04:02:24PM +0100, 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.
> 
> Now you're supposed to use cpu_in/cpu_out tracepoints instead.
> However for the majority of guests these tracepoints will never be
> called.
> 
> So this patch tries to rationalize all of that.  It:
> 
>  - replaces cpu_in/cpu_out with ioport_in/ioport_out tracepoints
> 
>  - moves them down in the stack, so they actually get called
> 
>  - fixes various details like address size
> 
> 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.  Maybe using a different tracing
> backend (eg. stap) would help?

With ftrace the granularity is simply on/off printf on a per-tracepoint
basis. With dtrace/systemtap you provide a hook that does whatever it
wants per-tracepoint. So assuming the arguments passed with the tracepoint
have the info, you can filter so it only prints on the ones you care about.

eg you've defined this new probe

 ioport_in(uint64_t addr, char size, uint64_t val) "addr %#"PRIx64"(%c) value 
%#"PRIx64
 ioport_out(uint64_t addr, char size, uint64_t val) "addr %#"PRIx64"(%c) value 
%#"PRIx64


so with systemtap you would  do

  probe qemu.ioport_in {
      printf("addr=%p size=%d val=%llu\n", addr, size, val)
  }

to get the same output as ftrace, but to filter it you would add
a conditional


  probe qemu.ioport_in {
      if (addr == 0xdeadbeef) {
        printf("addr=%p size=%d val=%llu\n", addr, size, val);
      }
  }

...assuming you have an easy way to figure out the correct value
of addr you want.

Since you have global state with systemtap you could record parameters
you want in one probe and reference them in later probes. eg you could
stick a probe on the serial port emulation which registers the i/O
port address to record the address associated with the serial port,
then use this address in the ioport_in probe.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|