From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] add some virtio-scsi trace events
Date: Thu, 29 Aug 2013 16:53:51 +0200 [thread overview]
Message-ID: <521F607F.70001@redhat.com> (raw)
In-Reply-To: <521F581A.50301@redhat.com>
Il 29/08/2013 16:18, Laszlo Ersek ha scritto:
> On 08/29/13 15:59, Paolo Bonzini wrote:
>> Il 29/08/2013 15:37, Laszlo Ersek ha scritto:
>>> The events that log a hexdump of the cdb and the sense buffer are disabled
>>> by default, because they require more processing than a simple trace_XXX()
>>> function call.
>>>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>
>> trace_event_get_state doesn't work with the dtrace backend. Can you
>> prepare v2 without those tracepoints?
>
> (a) I was just following "docs/tracing.txt"; see the last section in
> there.
>
> (b) If I kill those two events, this is what you get:
>
> Incoming request:
>
> virtio_scsi_handle_cmd_enter vdev 0x7f1be4054468 vq 0x7f1be4054b60
> virtio_scsi_pop_req req 0x7f1be5d77650
> virtio_scsi_handle_cmd_exit vdev 0x7f1be4054468 vq 0x7f1be4054b60
>
> This gives you the address of the request, so you can look up the
> corresponding completion. However you don't know the actual command
> (cdb) without "virtio_scsi_dump_cmd_req".
Yes, but you can see almost all of the cdb from scsi_req_parsed and
scsi_req_parsed_lba.
> virtio_scsi_command_complete_enter req 0x7f1be5d77650 status 2 resid 0
> virtio_scsi_complete_req_enter req 0x7f1be5d77650
> virtio_scsi_complete_req_exit req 0x7f1be5d77650
> virtio_scsi_command_complete_exit req 0x7f1be5d77650 status 2 resid 0 sense_len 18
>
> this will not tell you the virtio-scsi transport response code, or the
> actual sense data.
Same here: scsi_req_build_sense can give the sense data, and we could
add another tracepoint scsi_req_complete for the response code.
> (c) The way I submitted the series, the events in question are disabled
> in "trace-events". Check out the functions themselves: they are
> protected (ie. even the trace_event_get_state() calls are protected)
> with preprocessing directives. I did it this way because I call them in
> several places, and I wanted to keep the #if's centralized.
Tracing was supposed to remove the need for #if... :)
I'll try to salvage the patch.
Paolo
next prev parent reply other threads:[~2013-08-29 14:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-29 13:36 [Qemu-devel] [PATCH 0/2] some virtio-scsi tracing Laszlo Ersek
2013-08-29 13:37 ` [Qemu-devel] [PATCH 1/2] qemu_hexstr(): hexdump a small buffer to a string, for in-line printing Laszlo Ersek
2013-08-29 16:32 ` Markus Armbruster
2013-08-29 13:37 ` [Qemu-devel] [PATCH 2/2] add some virtio-scsi trace events Laszlo Ersek
2013-08-29 13:59 ` Paolo Bonzini
2013-08-29 14:18 ` Laszlo Ersek
2013-08-29 14:53 ` Paolo Bonzini [this message]
2013-08-29 15:35 ` Laszlo Ersek
2013-08-29 15:42 ` Paolo Bonzini
2013-09-04 14:21 ` Stefan Hajnoczi
2013-09-05 1:26 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=521F607F.70001@redhat.com \
--to=pbonzini@redhat.com \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.