Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-11 Thread Peter Maydell 
On 10 October 2017 at 09:02, Kevin Wolf  wrote:
> Assertions are for checking that assumptions in qemu code hold true.
> Here it's about bad guest code, and you can't let qemu abort for that.
>
> Tracing is the right tool to detect bad guest code, and I think it makes
> sense to mark conditions that shouldn't happen with a correctly
> operating guest driver. I'm not sure if an exclamation mark is the best
> syntax for this, because I wouldn't have intuitively understood what
> it's supposed to tell me.

We have qemu_log_mask(LOG_GUEST_ERROR, ...) for logging guest errors,
so I think we should use that.

thanks
-- PMM

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-11 Thread Doug Gale 
On Tue, Oct 10, 2017 at 4:02 AM, Kevin Wolf  wrote:
> Am 10.10.2017 um 08:58 hat Markus Armbruster geschrieben:
>> Doug Gale  writes:
>>
>> > I used exclamations as a concise way of indicating that the driver did
>> > something nonsensical, or horribly invalid, like something likely to
>> > cause a memory corruption, trying to start the controller with a
>> > nonsense configuration, providing invalid PRDs or writing to
>> > unrecognized MMIO offsets that might hang or do something extremely
>> > bad on a poorly implemented controller. Exclaiming is not shouting, I
>> > thought shouting was when it was all uppercase.
>> >
>> > If a driver might trash memory or hang a controller, maybe it should
>> > shout at the driver author or person investigating an unstable VM.
>> > None of those messages with exclamations should ever happen. If any of
>> > them are possible when the driver is correct, then I have made a
>> > mistake.
>>
>> Please do not top-quote on this mailing list.
>>
>> Existing tracepoints do not use exclamation marks to signal severity.
>>
>> Consider using assertions for "if this happens, either the program's
>> state is shot (and continuing is unsafe), or the author's mental state
>> was shot (and continuing is probably unsafe, too)" conditions.
>> Tracepoints are for tracing.
>
> Assertions are for checking that assumptions in qemu code hold true.
> Here it's about bad guest code, and you can't let qemu abort for that.
>
> Tracing is the right tool to detect bad guest code, and I think it makes
> sense to mark conditions that shouldn't happen with a correctly
> operating guest driver. I'm not sure if an exclamation mark is the best
> syntax for this, because I wouldn't have intuitively understood what
> it's supposed to tell me.
>
> If we do use the exclamation mark, we should document it somewhere
> (docs/devel/tracing.txt?) and make it a qemu-wide pattern. If not, we
> should choose something else and still document it and use it
> consistently.
>
> Kevin
>

Should I give up on indicating severity for now (removing the
exclamations) and just group together the severe ones with a comment
heading in the trace-events file?
I added "" at the end of some traces to help possibly-incorrect
parsing code find the end of the string reliably. Was that a good idea
or is it okay and expected to end them with something like PRIx64 and
drop the extra ""?
I found a few cases of missing 0x that I will fix in the next version
of this patch. Policy is to have 0x before every hex value, right?

Also, so I'm clear, when I submit the patch I should put the patch
first and put my message after the -- at the end?
And use "nvme: Add tracing" for the commit message,
And put nvme: Add tracing v3 in my subject line in a completely new
email thread?

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-10 Thread Kevin Wolf 
Am 10.10.2017 um 08:58 hat Markus Armbruster geschrieben:
> Doug Gale  writes:
> 
> > I used exclamations as a concise way of indicating that the driver did
> > something nonsensical, or horribly invalid, like something likely to
> > cause a memory corruption, trying to start the controller with a
> > nonsense configuration, providing invalid PRDs or writing to
> > unrecognized MMIO offsets that might hang or do something extremely
> > bad on a poorly implemented controller. Exclaiming is not shouting, I
> > thought shouting was when it was all uppercase.
> >
> > If a driver might trash memory or hang a controller, maybe it should
> > shout at the driver author or person investigating an unstable VM.
> > None of those messages with exclamations should ever happen. If any of
> > them are possible when the driver is correct, then I have made a
> > mistake.
> 
> Please do not top-quote on this mailing list.
> 
> Existing tracepoints do not use exclamation marks to signal severity.
> 
> Consider using assertions for "if this happens, either the program's
> state is shot (and continuing is unsafe), or the author's mental state
> was shot (and continuing is probably unsafe, too)" conditions.
> Tracepoints are for tracing.

Assertions are for checking that assumptions in qemu code hold true.
Here it's about bad guest code, and you can't let qemu abort for that.

Tracing is the right tool to detect bad guest code, and I think it makes
sense to mark conditions that shouldn't happen with a correctly
operating guest driver. I'm not sure if an exclamation mark is the best
syntax for this, because I wouldn't have intuitively understood what
it's supposed to tell me.

If we do use the exclamation mark, we should document it somewhere
(docs/devel/tracing.txt?) and make it a qemu-wide pattern. If not, we
should choose something else and still document it and use it
consistently.

Kevin

> > On Mon, Oct 9, 2017 at 11:52 AM, Eric Blake  wrote:
> >> On 10/07/2017 02:51 AM, Doug Gale wrote:
> >>> Completely re-implemented patch, with significant improvements (now
> >>> specifies values in several places I missed, also reduced the amount
> >>> of redundant lines). I used the nvme_ as the tracing infrastructure
> >>> prefix. Tested with -trace nvme_* on the qemu command line, worked for
> >>> me.
> >>
> >> This information belongs...
> >>
> >>>
> From 166f57458d60d363a10a0933c3e860985531ac96 Mon Sep 17 00:00:00 2001
> >>> From: Doug Gale 
> >>> Date: Thu, 5 Oct 2017 19:02:03 -0400
> >>> Subject: [PATCH] Add tracing output to NVMe emulation to help driver 
> >>> authors.
> >>>
> >>> This uses the tracing infrastructure using nvme_ as the prefix.
> >>>
> >>> Signed-off-by: Doug Gale 
> >>> ---
> >>
> >> ...here, after the --- separator.  It is useful to the patch reviewer,
> >> but does not need to be in the 'git log' history.  The maintainers use
> >> 'git am' to process incoming patches, which automatically prunes review
> >> comments located in this location.
> >>
> >> Also, since this is a version 2 patch, it is best if your subject line
> >> includes 'v2', and if you send the patch as a new top-level thread
> >> rather than in-reply-to v1.  This can be done with 'git send-email -v2'.
> >>
> >> The subject line is atypical; we tend to prefer 'topic: Short summary',
> >> where you are missing the topic, you had a trailing dot that is not
> >> typical, and where your line is longer than usual.  A better subject
> >> line might be:
> >>
> >> nvme: Add tracing output
> >>
> >>
> >> For more helpful information on patch submission:
> >>
> >> https://wiki.qemu.org/Contribute/SubmitAPatch
> >>
> >> I didn't look closely at the patch itself, but did notice:
> >>
> >>> +nvme_mmio_start_failed(void) "setting controller enable bit failed!"
> >>> +nvme_mmio_start_success(void) "setting controller enable bit succeeded"
> >>> +nvme_mmio_stopped(void) "cleared controller enable bit"
> >>> +nvme_mmio_shutdown_set(void) "shutdown bit set"
> >>> +nvme_mmio_shutdown_cleared(void) "shutdown bit cleared"
> >>> +nvme_mmio_ignored(uint64_t offset, uint64_t data) "invalid MMIO
> >>> write, offset=0x%"PRIx64", data=%"PRIx64"!"
> >>
> >> You have a couple of traces with a trailing '!'; that is atypical,
> >> because we don't need our traces to shout at the user.

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-10 Thread Markus Armbruster 
Doug Gale  writes:

> I used exclamations as a concise way of indicating that the driver did
> something nonsensical, or horribly invalid, like something likely to
> cause a memory corruption, trying to start the controller with a
> nonsense configuration, providing invalid PRDs or writing to
> unrecognized MMIO offsets that might hang or do something extremely
> bad on a poorly implemented controller. Exclaiming is not shouting, I
> thought shouting was when it was all uppercase.
>
> If a driver might trash memory or hang a controller, maybe it should
> shout at the driver author or person investigating an unstable VM.
> None of those messages with exclamations should ever happen. If any of
> them are possible when the driver is correct, then I have made a
> mistake.

Please do not top-quote on this mailing list.

Existing tracepoints do not use exclamation marks to signal severity.

Consider using assertions for "if this happens, either the program's
state is shot (and continuing is unsafe), or the author's mental state
was shot (and continuing is probably unsafe, too)" conditions.
Tracepoints are for tracing.

> On Mon, Oct 9, 2017 at 11:52 AM, Eric Blake  wrote:
>> On 10/07/2017 02:51 AM, Doug Gale wrote:
>>> Completely re-implemented patch, with significant improvements (now
>>> specifies values in several places I missed, also reduced the amount
>>> of redundant lines). I used the nvme_ as the tracing infrastructure
>>> prefix. Tested with -trace nvme_* on the qemu command line, worked for
>>> me.
>>
>> This information belongs...
>>
>>>
From 166f57458d60d363a10a0933c3e860985531ac96 Mon Sep 17 00:00:00 2001
>>> From: Doug Gale 
>>> Date: Thu, 5 Oct 2017 19:02:03 -0400
>>> Subject: [PATCH] Add tracing output to NVMe emulation to help driver 
>>> authors.
>>>
>>> This uses the tracing infrastructure using nvme_ as the prefix.
>>>
>>> Signed-off-by: Doug Gale 
>>> ---
>>
>> ...here, after the --- separator.  It is useful to the patch reviewer,
>> but does not need to be in the 'git log' history.  The maintainers use
>> 'git am' to process incoming patches, which automatically prunes review
>> comments located in this location.
>>
>> Also, since this is a version 2 patch, it is best if your subject line
>> includes 'v2', and if you send the patch as a new top-level thread
>> rather than in-reply-to v1.  This can be done with 'git send-email -v2'.
>>
>> The subject line is atypical; we tend to prefer 'topic: Short summary',
>> where you are missing the topic, you had a trailing dot that is not
>> typical, and where your line is longer than usual.  A better subject
>> line might be:
>>
>> nvme: Add tracing output
>>
>>
>> For more helpful information on patch submission:
>>
>> https://wiki.qemu.org/Contribute/SubmitAPatch
>>
>> I didn't look closely at the patch itself, but did notice:
>>
>>> +nvme_mmio_start_failed(void) "setting controller enable bit failed!"
>>> +nvme_mmio_start_success(void) "setting controller enable bit succeeded"
>>> +nvme_mmio_stopped(void) "cleared controller enable bit"
>>> +nvme_mmio_shutdown_set(void) "shutdown bit set"
>>> +nvme_mmio_shutdown_cleared(void) "shutdown bit cleared"
>>> +nvme_mmio_ignored(uint64_t offset, uint64_t data) "invalid MMIO
>>> write, offset=0x%"PRIx64", data=%"PRIx64"!"
>>
>> You have a couple of traces with a trailing '!'; that is atypical,
>> because we don't need our traces to shout at the user.

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-09 Thread Doug Gale 
I used exclamations as a concise way of indicating that the driver did
something nonsensical, or horribly invalid, like something likely to
cause a memory corruption, trying to start the controller with a
nonsense configuration, providing invalid PRDs or writing to
unrecognized MMIO offsets that might hang or do something extremely
bad on a poorly implemented controller. Exclaiming is not shouting, I
thought shouting was when it was all uppercase.

If a driver might trash memory or hang a controller, maybe it should
shout at the driver author or person investigating an unstable VM.
None of those messages with exclamations should ever happen. If any of
them are possible when the driver is correct, then I have made a
mistake.

On Mon, Oct 9, 2017 at 11:52 AM, Eric Blake  wrote:
> On 10/07/2017 02:51 AM, Doug Gale wrote:
>> Completely re-implemented patch, with significant improvements (now
>> specifies values in several places I missed, also reduced the amount
>> of redundant lines). I used the nvme_ as the tracing infrastructure
>> prefix. Tested with -trace nvme_* on the qemu command line, worked for
>> me.
>
> This information belongs...
>
>>
>>>From 166f57458d60d363a10a0933c3e860985531ac96 Mon Sep 17 00:00:00 2001
>> From: Doug Gale 
>> Date: Thu, 5 Oct 2017 19:02:03 -0400
>> Subject: [PATCH] Add tracing output to NVMe emulation to help driver authors.
>>
>> This uses the tracing infrastructure using nvme_ as the prefix.
>>
>> Signed-off-by: Doug Gale 
>> ---
>
> ...here, after the --- separator.  It is useful to the patch reviewer,
> but does not need to be in the 'git log' history.  The maintainers use
> 'git am' to process incoming patches, which automatically prunes review
> comments located in this location.
>
> Also, since this is a version 2 patch, it is best if your subject line
> includes 'v2', and if you send the patch as a new top-level thread
> rather than in-reply-to v1.  This can be done with 'git send-email -v2'.
>
> The subject line is atypical; we tend to prefer 'topic: Short summary',
> where you are missing the topic, you had a trailing dot that is not
> typical, and where your line is longer than usual.  A better subject
> line might be:
>
> nvme: Add tracing output
>
>
> For more helpful information on patch submission:
>
> https://wiki.qemu.org/Contribute/SubmitAPatch
>
> I didn't look closely at the patch itself, but did notice:
>
>> +nvme_mmio_start_failed(void) "setting controller enable bit failed!"
>> +nvme_mmio_start_success(void) "setting controller enable bit succeeded"
>> +nvme_mmio_stopped(void) "cleared controller enable bit"
>> +nvme_mmio_shutdown_set(void) "shutdown bit set"
>> +nvme_mmio_shutdown_cleared(void) "shutdown bit cleared"
>> +nvme_mmio_ignored(uint64_t offset, uint64_t data) "invalid MMIO
>> write, offset=0x%"PRIx64", data=%"PRIx64"!"
>
> You have a couple of traces with a trailing '!'; that is atypical,
> because we don't need our traces to shout at the user.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-09 Thread Eric Blake 
On 10/07/2017 02:51 AM, Doug Gale wrote:
> Completely re-implemented patch, with significant improvements (now
> specifies values in several places I missed, also reduced the amount
> of redundant lines). I used the nvme_ as the tracing infrastructure
> prefix. Tested with -trace nvme_* on the qemu command line, worked for
> me.

This information belongs...

> 
>>From 166f57458d60d363a10a0933c3e860985531ac96 Mon Sep 17 00:00:00 2001
> From: Doug Gale 
> Date: Thu, 5 Oct 2017 19:02:03 -0400
> Subject: [PATCH] Add tracing output to NVMe emulation to help driver authors.
> 
> This uses the tracing infrastructure using nvme_ as the prefix.
> 
> Signed-off-by: Doug Gale 
> ---

...here, after the --- separator.  It is useful to the patch reviewer,
but does not need to be in the 'git log' history.  The maintainers use
'git am' to process incoming patches, which automatically prunes review
comments located in this location.

Also, since this is a version 2 patch, it is best if your subject line
includes 'v2', and if you send the patch as a new top-level thread
rather than in-reply-to v1.  This can be done with 'git send-email -v2'.

The subject line is atypical; we tend to prefer 'topic: Short summary',
where you are missing the topic, you had a trailing dot that is not
typical, and where your line is longer than usual.  A better subject
line might be:

nvme: Add tracing output


For more helpful information on patch submission:

https://wiki.qemu.org/Contribute/SubmitAPatch

I didn't look closely at the patch itself, but did notice:

> +nvme_mmio_start_failed(void) "setting controller enable bit failed!"
> +nvme_mmio_start_success(void) "setting controller enable bit succeeded"
> +nvme_mmio_stopped(void) "cleared controller enable bit"
> +nvme_mmio_shutdown_set(void) "shutdown bit set"
> +nvme_mmio_shutdown_cleared(void) "shutdown bit cleared"
> +nvme_mmio_ignored(uint64_t offset, uint64_t data) "invalid MMIO
> write, offset=0x%"PRIx64", data=%"PRIx64"!"

You have a couple of traces with a trailing '!'; that is atypical,
because we don't need our traces to shout at the user.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-07 Thread Doug Gale 
Completely re-implemented patch, with significant improvements (now
specifies values in several places I missed, also reduced the amount
of redundant lines). I used the nvme_ as the tracing infrastructure
prefix. Tested with -trace nvme_* on the qemu command line, worked for
me.

>From 166f57458d60d363a10a0933c3e860985531ac96 Mon Sep 17 00:00:00 2001
From: Doug Gale 
Date: Thu, 5 Oct 2017 19:02:03 -0400
Subject: [PATCH] Add tracing output to NVMe emulation to help driver authors.

This uses the tracing infrastructure using nvme_ as the prefix.

Signed-off-by: Doug Gale 
---
 hw/block/nvme.c   | 158 +-
 hw/block/trace-events |  89 
 2 files changed, 233 insertions(+), 14 deletions(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 9aa32692a3..3e3cd820a3 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -34,6 +34,7 @@
 #include "qapi/visitor.h"
 #include "sysemu/block-backend.h"

+#include "trace.h"
 #include "nvme.h"

 static void nvme_process_sq(void *opaque);
@@ -86,10 +87,14 @@ static void nvme_isr_notify(NvmeCtrl *n, NvmeCQueue *cq)
 {
 if (cq->irq_enabled) {
 if (msix_enabled(&(n->parent_obj))) {
+trace_nvme_msix_intr(cq->vector);
 msix_notify(&(n->parent_obj), cq->vector);
 } else {
+trace_nvme_pin_intr();
 pci_irq_pulse(>parent_obj);
 }
+} else {
+trace_nvme_masked_intr();
 }
 }

@@ -101,6 +106,7 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg,
QEMUIOVector *iov, uint64_t prp1,
 int num_prps = (len >> n->page_bits) + 1;

 if (!prp1) {
+trace_nvme_invalid_prp();
 return NVME_INVALID_FIELD | NVME_DNR;
 } else if (n->cmbsz && prp1 >= n->ctrl_mem.addr &&
prp1 < n->ctrl_mem.addr + int128_get64(n->ctrl_mem.size)) {
@@ -114,6 +120,7 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg,
QEMUIOVector *iov, uint64_t prp1,
 len -= trans_len;
 if (len) {
 if (!prp2) {
+trace_nvme_invalid_prp2_missing();
 goto unmap;
 }
 if (len > n->page_size) {
@@ -129,6 +136,7 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg,
QEMUIOVector *iov, uint64_t prp1,

 if (i == n->max_prp_ents - 1 && len > n->page_size) {
 if (!prp_ent || prp_ent & (n->page_size - 1)) {
+trace_nvme_invalid_prplist_ent(prp_ent);
 goto unmap;
 }

@@ -141,6 +149,7 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg,
QEMUIOVector *iov, uint64_t prp1,
 }

 if (!prp_ent || prp_ent & (n->page_size - 1)) {
+trace_nvme_invalid_prplist_ent(prp_ent);
 goto unmap;
 }

@@ -155,6 +164,7 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg,
QEMUIOVector *iov, uint64_t prp1,
 }
 } else {
 if (prp2 & (n->page_size - 1)) {
+trace_nvme_invalid_prp2_align(prp2);
 goto unmap;
 }
 if (qsg->nsg) {
@@ -178,16 +188,20 @@ static uint16_t nvme_dma_read_prp(NvmeCtrl *n,
uint8_t *ptr, uint32_t len,
 QEMUIOVector iov;
 uint16_t status = NVME_SUCCESS;

+trace_nvme_dma_read(prp1, prp2);
+
 if (nvme_map_prp(, , prp1, prp2, len, n)) {
 return NVME_INVALID_FIELD | NVME_DNR;
 }
 if (qsg.nsg > 0) {
 if (dma_buf_read(ptr, len, )) {
+trace_nvme_dma_too_short();
 status = NVME_INVALID_FIELD | NVME_DNR;
 }
 qemu_sglist_destroy();
 } else {
 if (qemu_iovec_to_buf(, 0, ptr, len) != len) {
+trace_nvme_dma_too_short();
 status = NVME_INVALID_FIELD | NVME_DNR;
 }
 qemu_iovec_destroy();
@@ -274,6 +288,7 @@ static uint16_t nvme_write_zeros(NvmeCtrl *n,
NvmeNamespace *ns, NvmeCmd *cmd,
 uint32_t aio_nlb = nlb << (data_shift - BDRV_SECTOR_BITS);

 if (slba + nlb > ns->id_ns.nsze) {
+trace_nvme_invalid_lba_range(slba, nlb, ns->id_ns.nsze);
 return NVME_LBA_RANGE | NVME_DNR;
 }

@@ -301,8 +316,11 @@ static uint16_t nvme_rw(NvmeCtrl *n,
NvmeNamespace *ns, NvmeCmd *cmd,
 int is_write = rw->opcode == NVME_CMD_WRITE ? 1 : 0;
 enum BlockAcctType acct = is_write ? BLOCK_ACCT_WRITE : BLOCK_ACCT_READ;

+trace_nvme_rw(is_write ? "write" : "read", nlb, data_size, slba);
+
 if ((slba + nlb) > ns->id_ns.nsze) {
 block_acct_invalid(blk_get_stats(n->conf.blk), acct);
+trace_nvme_invalid_lba_range(slba, nlb, ns->id_ns.nsze);
 return NVME_LBA_RANGE | NVME_DNR;
 }

@@ -337,6 +355,7 @@ static uint16_t nvme_io_cmd(NvmeCtrl *n, NvmeCmd
*cmd, NvmeRequest *req)
 uint32_t nsid = le32_to_cpu(cmd->nsid);

 if (nsid == 0 || nsid > n->num_namespaces) {
+trace_nvme_invalid_ns(nsid, n->num_namespaces);
 return NVME_INVALID_NSID |

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-06 Thread Daniel P. Berrange 
On Fri, Oct 06, 2017 at 09:58:33AM -0400, Doug Gale wrote:
> I tried to get tracing to work before and I have never gotten it
> working. I'll give it another try and redo the patch with tracing
> infrastructure if necessary. The printf are nice because the dev can
> just look at the terminal where qemu is running. Can you view the
> trace output in realtime? When their code is sitting at a breakpoint
> in their driver, can they see the last thing that was traced right
> there? Or do they have to go run some cumbersome command and wade
> through it after an entire test run after the vm shut down?

There's a variety of trace backends available. By default QEMU enables
the 'log' backend these days. So with a default build of QEMU you can
use the '-d' arg to turn on printing: eg.:

   qemu-system-x86_64 ...args...-d trace:qio*

and that'll turn on every tracepoint with 'qio' as a prefix. The
trace messages will be printed straight to the console. eg:

$ qemu-system-x86_64 -d trace:qio* -serial unix:/tmp/foo,server
15774@1507298448.842745:qio_channel_socket_new Socket new ioc=0x5598b0565d60
15774@1507298448.842757:qio_channel_socket_listen_sync Socket listen sync 
ioc=0x5598b0565d60 addr=0x5598b0565c50
15774@1507298448.842803:qio_channel_socket_listen_complete Socket listen 
complete ioc=0x5598b0565d60 fd=16
qemu-system-x86_64: -serial unix:/tmp/foo,server: info: QEMU waiting for 
connection on: disconnected:unix:/tmp/foo,server
15774@1507298448.842818:qio_channel_socket_new Socket new ioc=0x5598b0564060
15774@1507298448.842820:qio_channel_socket_accept Socket accept start 
ioc=0x5598b0565d60


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-06 Thread Doug Gale 
I tried to get tracing to work before and I have never gotten it
working. I'll give it another try and redo the patch with tracing
infrastructure if necessary. The printf are nice because the dev can
just look at the terminal where qemu is running. Can you view the
trace output in realtime? When their code is sitting at a breakpoint
in their driver, can they see the last thing that was traced right
there? Or do they have to go run some cumbersome command and wade
through it after an entire test run after the vm shut down?


On Fri, Oct 6, 2017 at 9:54 AM, Daniel P. Berrange  wrote:
> On Fri, Oct 06, 2017 at 08:50:31AM -0500, Eric Blake wrote:
>> On 10/05/2017 06:18 PM, Doug Gale wrote:
>> > I added the tracing output in this patch to assist me in implementing
>> > an NVMe driver. It helped tremendously.
>> >
>> >>From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
>> > From: Doug Gale 
>> > Date: Thu, 5 Oct 2017 19:02:03 -0400
>> > Subject: [PATCH] Add tracing output to NVMe emulation to help driver 
>> > authors.
>> >
>> > It is off by default, enable it by uncommenting #define DEBUG_NVME
>> > or through CFLAGS
>> >
>> > Signed-off-by: Doug Gale 
>> > ---
>> >  hw/block/nvme.c | 191 
>> > +++-
>> >  1 file changed, 177 insertions(+), 14 deletions(-)
>> >
>> > diff --git a/hw/block/nvme.c b/hw/block/nvme.c
>> > index 9aa32692a3..74220c0171 100644
>> > --- a/hw/block/nvme.c
>> > +++ b/hw/block/nvme.c
>> > @@ -36,6 +36,14 @@
>> >
>> >  #include "nvme.h"
>> >
>> > +//#define DEBUG_NVME
>> > +
>> > +#ifdef DEBUG_NVME
>> > +#define DPRINTF(fmt, ...) fprintf(stderr, "nvme: " fmt "\n", ## 
>> > __VA_ARGS__)
>> > +#else
>> > +#define DPRINTF(fmt, ...) ((void)0)
>> > +#endif
>>
>> As Kevin said, using trace-events is nicer than fprintf().  But if you
>> absolutely insist on fprintf(), then do NOT do it like this, because
>> this leads to bit-rot.  Instead, do it in a form that lets -Wformat
>> checking work even when tracing is disabled:
>
> [snip]
>
> IMHO using of trace() instead of fprintf() is pretty much mandatory
> at this point. We've been making a concious effort to replace fprintfs
> with trace across code, so shouldn't add more fprintfs. It is just so
> much more useful to be able to enable the debugging without having to
> recompile the binary.
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-06 Thread Daniel P. Berrange 
On Fri, Oct 06, 2017 at 08:50:31AM -0500, Eric Blake wrote:
> On 10/05/2017 06:18 PM, Doug Gale wrote:
> > I added the tracing output in this patch to assist me in implementing
> > an NVMe driver. It helped tremendously.
> > 
> >>From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
> > From: Doug Gale 
> > Date: Thu, 5 Oct 2017 19:02:03 -0400
> > Subject: [PATCH] Add tracing output to NVMe emulation to help driver 
> > authors.
> > 
> > It is off by default, enable it by uncommenting #define DEBUG_NVME
> > or through CFLAGS
> > 
> > Signed-off-by: Doug Gale 
> > ---
> >  hw/block/nvme.c | 191 
> > +++-
> >  1 file changed, 177 insertions(+), 14 deletions(-)
> > 
> > diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> > index 9aa32692a3..74220c0171 100644
> > --- a/hw/block/nvme.c
> > +++ b/hw/block/nvme.c
> > @@ -36,6 +36,14 @@
> > 
> >  #include "nvme.h"
> > 
> > +//#define DEBUG_NVME
> > +
> > +#ifdef DEBUG_NVME
> > +#define DPRINTF(fmt, ...) fprintf(stderr, "nvme: " fmt "\n", ## 
> > __VA_ARGS__)
> > +#else
> > +#define DPRINTF(fmt, ...) ((void)0)
> > +#endif
> 
> As Kevin said, using trace-events is nicer than fprintf().  But if you
> absolutely insist on fprintf(), then do NOT do it like this, because
> this leads to bit-rot.  Instead, do it in a form that lets -Wformat
> checking work even when tracing is disabled:

[snip]

IMHO using of trace() instead of fprintf() is pretty much mandatory
at this point. We've been making a concious effort to replace fprintfs
with trace across code, so shouldn't add more fprintfs. It is just so
much more useful to be able to enable the debugging without having to
recompile the binary.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-06 Thread Eric Blake 
On 10/05/2017 06:18 PM, Doug Gale wrote:
> I added the tracing output in this patch to assist me in implementing
> an NVMe driver. It helped tremendously.
> 
>>From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
> From: Doug Gale 
> Date: Thu, 5 Oct 2017 19:02:03 -0400
> Subject: [PATCH] Add tracing output to NVMe emulation to help driver authors.
> 
> It is off by default, enable it by uncommenting #define DEBUG_NVME
> or through CFLAGS
> 
> Signed-off-by: Doug Gale 
> ---
>  hw/block/nvme.c | 191 
> +++-
>  1 file changed, 177 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> index 9aa32692a3..74220c0171 100644
> --- a/hw/block/nvme.c
> +++ b/hw/block/nvme.c
> @@ -36,6 +36,14 @@
> 
>  #include "nvme.h"
> 
> +//#define DEBUG_NVME
> +
> +#ifdef DEBUG_NVME
> +#define DPRINTF(fmt, ...) fprintf(stderr, "nvme: " fmt "\n", ## __VA_ARGS__)
> +#else
> +#define DPRINTF(fmt, ...) ((void)0)
> +#endif

As Kevin said, using trace-events is nicer than fprintf().  But if you
absolutely insist on fprintf(), then do NOT do it like this, because
this leads to bit-rot.  Instead, do it in a form that lets -Wformat
checking work even when tracing is disabled:

#ifdef DEBUG_NVME
# define DEBUG_NVME_PRINT 1
#else
# define DEBUG_NVME_PRINT 0
#endif
#define DPRINTF(fmt, ...) \
do { \
if (DEBUG_NVME_PRINT) { \
fprintf(stderr, "nvme: " fmt "\n", ## __VA_ARGS__); \
} \
while (0)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-06 Thread Kevin Wolf 
Am 06.10.2017 um 01:18 hat Doug Gale geschrieben:
> I added the tracing output in this patch to assist me in implementing
> an NVMe driver. It helped tremendously.
> 
> From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
> From: Doug Gale 
> Date: Thu, 5 Oct 2017 19:02:03 -0400
> Subject: [PATCH] Add tracing output to NVMe emulation to help driver authors.
> 
> It is off by default, enable it by uncommenting #define DEBUG_NVME
> or through CFLAGS
> 
> Signed-off-by: Doug Gale 

I think it's generally preferable to use the actual tracing
infrastructure instead of fprintf. This would allow to enable the trace
points with the command line options instead of only at compile time and
also to get machine-readable output if necessary.

The tracing infrastructure is documented in docs/devel/tracing.txt.

Kevin

[Qemu-devel] Patch to add helpful tracing output for driver authors in NVMe emulation

2017-10-05 Thread Doug Gale 
I added the tracing output in this patch to assist me in implementing
an NVMe driver. It helped tremendously.

>From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
From: Doug Gale 
Date: Thu, 5 Oct 2017 19:02:03 -0400
Subject: [PATCH] Add tracing output to NVMe emulation to help driver authors.

It is off by default, enable it by uncommenting #define DEBUG_NVME
or through CFLAGS

Signed-off-by: Doug Gale 
---
 hw/block/nvme.c | 191 +++-
 1 file changed, 177 insertions(+), 14 deletions(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 9aa32692a3..74220c0171 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -36,6 +36,14 @@

 #include "nvme.h"

+//#define DEBUG_NVME
+
+#ifdef DEBUG_NVME
+#define DPRINTF(fmt, ...) fprintf(stderr, "nvme: " fmt "\n", ## __VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...) ((void)0)
+#endif
+
 static void nvme_process_sq(void *opaque);

 static void nvme_addr_read(NvmeCtrl *n, hwaddr addr, void *buf, int size)
@@ -86,10 +94,14 @@ static void nvme_isr_notify(NvmeCtrl *n, NvmeCQueue *cq)
 {
 if (cq->irq_enabled) {
 if (msix_enabled(&(n->parent_obj))) {
+DPRINTF("raising MSI-X IRQ vector %u", cq->vector);
 msix_notify(&(n->parent_obj), cq->vector);
 } else {
+DPRINTF("pulsing IRQ pin");
 pci_irq_pulse(>parent_obj);
 }
+} else {
+DPRINTF("IRQ is masked");
 }
 }

@@ -101,9 +113,11 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg,
QEMUIOVector *iov, uint64_t prp1,
 int num_prps = (len >> n->page_bits) + 1;

 if (!prp1) {
+DPRINTF("Invalid PRP!");
 return NVME_INVALID_FIELD | NVME_DNR;
 } else if (n->cmbsz && prp1 >= n->ctrl_mem.addr &&
prp1 < n->ctrl_mem.addr + int128_get64(n->ctrl_mem.size)) {
+DPRINTF("PRP in controller memory");
 qsg->nsg = 0;
 qemu_iovec_init(iov, num_prps);
 qemu_iovec_add(iov, (void *)>cmbuf[prp1 -
n->ctrl_mem.addr], trans_len);
@@ -168,6 +182,7 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg,
QEMUIOVector *iov, uint64_t prp1,

  unmap:
 qemu_sglist_destroy(qsg);
+DPRINTF("invalid SGL!");
 return NVME_INVALID_FIELD | NVME_DNR;
 }

@@ -178,16 +193,22 @@ static uint16_t nvme_dma_read_prp(NvmeCtrl *n,
uint8_t *ptr, uint32_t len,
 QEMUIOVector iov;
 uint16_t status = NVME_SUCCESS;

+DPRINTF("DMA read, prp1=0x%"PRIx64" prp2=0x%"PRIx64,
+prp1, prp2);
+
 if (nvme_map_prp(, , prp1, prp2, len, n)) {
+DPRINTF("DMA read invalid PRP field!");
 return NVME_INVALID_FIELD | NVME_DNR;
 }
 if (qsg.nsg > 0) {
 if (dma_buf_read(ptr, len, )) {
+DPRINTF("DMA read invalid SGL field!");
 status = NVME_INVALID_FIELD | NVME_DNR;
 }
 qemu_sglist_destroy();
 } else {
 if (qemu_iovec_to_buf(, 0, ptr, len) != len) {
+DPRINTF("invalid field!");
 status = NVME_INVALID_FIELD | NVME_DNR;
 }
 qemu_iovec_destroy();
@@ -274,6 +295,7 @@ static uint16_t nvme_write_zeros(NvmeCtrl *n,
NvmeNamespace *ns, NvmeCmd *cmd,
 uint32_t aio_nlb = nlb << (data_shift - BDRV_SECTOR_BITS);

 if (slba + nlb > ns->id_ns.nsze) {
+DPRINTF("Invalid LBA!");
 return NVME_LBA_RANGE | NVME_DNR;
 }

@@ -301,13 +323,19 @@ static uint16_t nvme_rw(NvmeCtrl *n,
NvmeNamespace *ns, NvmeCmd *cmd,
 int is_write = rw->opcode == NVME_CMD_WRITE ? 1 : 0;
 enum BlockAcctType acct = is_write ? BLOCK_ACCT_WRITE : BLOCK_ACCT_READ;

+DPRINTF("%s %"PRIu32" blocks (%"PRIu64" bytes) from LBA %"PRIu64,
+is_write ? "write" : "read",
+nlb, data_size, slba);
+
 if ((slba + nlb) > ns->id_ns.nsze) {
 block_acct_invalid(blk_get_stats(n->conf.blk), acct);
+DPRINTF("Invalid LBA!");
 return NVME_LBA_RANGE | NVME_DNR;
 }

 if (nvme_map_prp(>qsg, >iov, prp1, prp2, data_size, n)) {
 block_acct_invalid(blk_get_stats(n->conf.blk), acct);
+DPRINTF("Invalid PRP!");
 return NVME_INVALID_FIELD | NVME_DNR;
 }

@@ -337,6 +365,7 @@ static uint16_t nvme_io_cmd(NvmeCtrl *n, NvmeCmd
*cmd, NvmeRequest *req)
 uint32_t nsid = le32_to_cpu(cmd->nsid);

 if (nsid == 0 || nsid > n->num_namespaces) {
+DPRINTF("Invalid namespace!");
 return NVME_INVALID_NSID | NVME_DNR;
 }

@@ -350,6 +379,7 @@ static uint16_t nvme_io_cmd(NvmeCtrl *n, NvmeCmd
*cmd, NvmeRequest *req)
 case NVME_CMD_READ:
 return nvme_rw(n, ns, cmd, req);
 default:
+DPRINTF("Invalid opcode!");
 return NVME_INVALID_OPCODE | NVME_DNR;
 }
 }
@@ -374,9 +404,12 @@ static uint16_t nvme_del_sq(NvmeCtrl *n, NvmeCmd *cmd)
 uint16_t qid = le16_to_cpu(c->qid);

 if (!qid || nvme_check_sqid(n, qid)) {
+DPRINTF("invalid submission queue deletion! qid=%u", qid);
 return