From: Shimi Gersner <gersner@gmail.com>
To: qemu-block@nongnu.org, qemu-devel@nongnu.org
Cc: Keith Busch <keith.busch@intel.com>,
Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
David Sariel <davidsa@openu.ac.il>,
Shimi Gersner <gersner@gmail.com>
Subject: [Qemu-devel] [PATCH 4/5] nvme: Fix phantom irq raise
Date: Fri, 22 Jun 2018 11:22:36 +0000 [thread overview]
Message-ID: <20180622112237.2131-4-gersner@gmail.com> (raw)
In-Reply-To: <20180622112237.2131-1-gersner@gmail.com>
CQ irq is asserted when requested are ready for the guest to
collect. On edge cases, irq is raised when there is no actual
request pending on the queue.
Irq is raised for a CQ from nvme_post_cqes uncondtionally
if there are processes requests or not. nvme_post_cqes is
triggered through timer in two cases
- Completion of sync or async request.
- CQ was emptied by the guest and pending responses may be queued.
Consider the following flow
- Async request is made while CQ is full.
- Guest reads entire CQ and triggers a DB. nvme_post_cqes is scheduled
and executed through timer.
- Async request is complete and nvme_post_cqes is scheduled
and executed through timer.
As nvme_post_cqes raises the irq unconditionally, it leads to
a raise of the irq while no pending CQ request is ready.
Issue is fixed by adding a fast path exit to nvme_post_cqes when it has
no pending processing hence no need to raise the irq.
Change-Id: Ib7af6c1bcb63d03022d9b57e079fdb2cf954e7dc
Signed-off-by: Shimi Gersner <gersner@gmail.com>
---
hw/block/nvme.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 206d8428fd..f639d7ae73 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -265,6 +265,11 @@ static void nvme_post_cqes(void *opaque)
NvmeCtrl *n = cq->ctrl;
NvmeRequest *req, *next;
+ // Fast path if nothing to be processed
+ if (QTAILQ_EMPTY(&cq->req_list)) {
+ return;
+ }
+
QTAILQ_FOREACH_SAFE(req, &cq->req_list, entry, next) {
NvmeSQueue *sq;
hwaddr addr;
@@ -1130,14 +1135,21 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val)
return;
}
+ /*
+ CLARIFICATION
+ When CQ was full *before* the db write, nvme_post_cqes skipped processing of responses and
+ as a side effect SQ was unable to process new requests (As they are limited by size).
+ When CQ is cleared, spawn both processing of all CQs and SQs. As call to timer_mod
+ is serial, first handle the CQ to clear any pending requests and then clear the associated SQs.
+ */
start_sqs = nvme_cq_full(cq) ? 1 : 0;
cq->head = new_head;
if (start_sqs) {
NvmeSQueue *sq;
+ timer_mod(cq->timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 500);
QTAILQ_FOREACH(sq, &cq->sq_list, entry) {
timer_mod(sq->timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 500);
}
- timer_mod(cq->timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 500);
}
if (cq->tail == cq->head) {
--
2.17.1
next prev parent reply other threads:[~2018-06-22 11:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-22 11:22 [Qemu-devel] [PATCH 1/5] nvme: PCI/e configuration from specification Shimi Gersner
2018-06-22 11:22 ` [Qemu-devel] [PATCH 2/5] nvme: CQ/SQ proper validation & status code Shimi Gersner
2018-06-22 11:22 ` [Qemu-devel] [PATCH 3/5] nvme: Proper state handling on enable/disable Shimi Gersner
2018-06-22 11:22 ` Shimi Gersner [this message]
2018-06-22 11:22 ` [Qemu-devel] [PATCH 5/5] nvme: Missing MSI message upon partial CQ read Shimi Gersner
2018-07-12 11:47 ` [Qemu-devel] [PATCH 1/5] nvme: PCI/e configuration from specification Kevin Wolf
2018-07-13 7:40 ` David Sariel
2018-07-15 6:20 ` Daniel Verkamp
2018-08-26 21:49 ` Gersner
2018-08-30 15:45 ` Daniel Verkamp
2018-09-12 19:53 ` Gersner
2018-09-12 21:21 ` Eric Blake
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=20180622112237.2131-4-gersner@gmail.com \
--to=gersner@gmail.com \
--cc=davidsa@openu.ac.il \
--cc=keith.busch@intel.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).