[Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination

All of lore.kernel.org
 help / color / mirror / Atom feed

* [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
@ 2016-09-21 13:13 Greg Kurz
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error Greg Kurz
                   ` (8 more replies)
  0 siblings, 9 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:13 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

This series is a follow up to Stefan's work to eradicate most calls to
exit() we currently have in the virtio code.

It addresses all exit() call sites in the blk, net and scsi device code,
where the error is about a missing or malformed in/out header sent by
the guest. They are converted to use virtio_error() and stop any processing,
instead of exiting.

The remaining call sites are related to a host misconfiguration or a
migration stream issue.

The 9P code currently calls assert() instead of exit(), but it also about
malformed or missing headers, so it gets converted the same way.

Next work will be to check all assert() call sites in the device code, in
case some of them actually refer to a bug in the guest, and should be
converted to use virtio_error() as well.

---

Greg Kurz (7):
      virtio-9p: handle handle_9p_output() error
      virtio-blk: handle virtio_blk_handle_request() errors
      virtio-net: handle virtio_net_handle_ctrl() error
      virtio-net: handle virtio_net_receive() errors
      virtio-net: handle virtio_net_flush_tx() errors
      virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
      virtio-scsi: handle virtio_scsi_set_config() error

 hw/9pfs/virtio-9p-device.c |   14 ++++++++++--
 hw/block/virtio-blk.c      |   27 +++++++++++++++--------
 hw/net/virtio-net.c        |   51 +++++++++++++++++++++++++-------------------
 hw/scsi/virtio-scsi.c      |   21 ++++++++++--------
 4 files changed, 70 insertions(+), 43 deletions(-)

--
Greg

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
@ 2016-09-21 13:14 ` Greg Kurz
  2016-09-21 14:16   ` Cornelia Huck
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors Greg Kurz
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:14 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

A broken guest may send a request with only non-empty out buffers
or only non-empty in buffers, virtqueue_pop() will then return a
VirtQueueElement with out_num == 0 or in_num == 0 respectively.

All 9P requests are expected to start with the following 7-byte header:

            uint32_t size_le;
            uint8_t id;
            uint16_t tag_le;

If iov_to_buf() fails to return these 7 bytes, then something is wrong in
the guest.

In both cases, it is wrong to crash QEMU, since the root cause lies in the
guest. Let's switch the device to the broken state instead.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/9pfs/virtio-9p-device.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 009b43f6d045..0f09bef13392 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -56,13 +56,23 @@ static void handle_9p_output(VirtIODevice *vdev, VirtQueue *vq)
             break;
         }
 
-        BUG_ON(elem->out_num == 0 || elem->in_num == 0);
+        if (elem->out_num == 0 || elem->in_num == 0) {
+            virtio_error(vdev,
+                         "The guest sent a VirtFS request without headers");
+            pdu_free(pdu);
+            return;
+        }
         QEMU_BUILD_BUG_ON(sizeof out != 7);
 
         v->elems[pdu->idx] = elem;
         len = iov_to_buf(elem->out_sg, elem->out_num, 0,
                          &out, sizeof out);
-        BUG_ON(len != sizeof out);
+        if (len != sizeof out) {
+            virtio_error(vdev, "The guest sent a malformed VirtFS request: "
+                         "header size is %zd, should be 7", len);
+            pdu_free(pdu);
+            return;
+        }
 
         pdu->size = le32_to_cpu(out.size_le);
 

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error Greg Kurz
@ 2016-09-21 13:14 ` Greg Kurz
  2016-09-21 14:28   ` Cornelia Huck
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error Greg Kurz
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:14 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

All these errors are caused by a buggy guest: let's switch the device to
the broken state instead of terminating QEMU.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/block/virtio-blk.c |   27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 3a6112fbf4c4..1285d196a40f 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -468,30 +468,32 @@ static bool virtio_blk_sect_range_ok(VirtIOBlock *dev,
     return true;
 }
 
-void virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
+int virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
 {
     uint32_t type;
     struct iovec *in_iov = req->elem.in_sg;
     struct iovec *iov = req->elem.out_sg;
     unsigned in_num = req->elem.in_num;
     unsigned out_num = req->elem.out_num;
+    VirtIOBlock *s = req->dev;
+    VirtIODevice *vdev = VIRTIO_DEVICE(s);
 
     if (req->elem.out_num < 1 || req->elem.in_num < 1) {
-        error_report("virtio-blk missing headers");
-        exit(1);
+        virtio_error(vdev, "virtio-blk missing headers");
+        return -1;
     }
 
     if (unlikely(iov_to_buf(iov, out_num, 0, &req->out,
                             sizeof(req->out)) != sizeof(req->out))) {
-        error_report("virtio-blk request outhdr too short");
-        exit(1);
+        virtio_error(vdev, "virtio-blk request outhdr too short");
+        return -1;
     }
 
     iov_discard_front(&iov, &out_num, sizeof(req->out));
 
     if (in_iov[in_num - 1].iov_len < sizeof(struct virtio_blk_inhdr)) {
-        error_report("virtio-blk request inhdr too short");
-        exit(1);
+        virtio_error(vdev, "virtio-blk request inhdr too short");
+        return -1;
     }
 
     /* We always touch the last byte, so just see how big in_iov is.  */
@@ -529,7 +531,7 @@ void virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
             block_acct_invalid(blk_get_stats(req->dev->blk),
                                is_write ? BLOCK_ACCT_WRITE : BLOCK_ACCT_READ);
             virtio_blk_free_request(req);
-            return;
+            return 0;
         }
 
         block_acct_start(blk_get_stats(req->dev->blk),
@@ -576,6 +578,7 @@ void virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
         virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
         virtio_blk_free_request(req);
     }
+    return 0;
 }
 
 void virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
@@ -586,7 +589,9 @@ void virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
     blk_io_plug(s->blk);
 
     while ((req = virtio_blk_get_request(s, vq))) {
-        virtio_blk_handle_request(req, &mrb);
+        if (virtio_blk_handle_request(req, &mrb)) {
+            return;
+        }
     }
 
     if (mrb.num_reqs) {
@@ -625,7 +630,9 @@ static void virtio_blk_dma_restart_bh(void *opaque)
 
     while (req) {
         VirtIOBlockReq *next = req->next;
-        virtio_blk_handle_request(req, &mrb);
+        if (virtio_blk_handle_request(req, &mrb)) {
+            return;
+        }
         req = next;
     }
 

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error Greg Kurz
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors Greg Kurz
@ 2016-09-21 13:14 ` Greg Kurz
  2016-09-21 14:30   ` Cornelia Huck
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 4/7] virtio-net: handle virtio_net_receive() errors Greg Kurz
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:14 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

This error is caused by a buggy guest: let's switch the device to the
broken state instead of terminating QEMU.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/net/virtio-net.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 01f1351554aa..68a448acd81b 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -892,8 +892,8 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
         }
         if (iov_size(elem->in_sg, elem->in_num) < sizeof(status) ||
             iov_size(elem->out_sg, elem->out_num) < sizeof(ctrl)) {
-            error_report("virtio-net ctrl missing headers");
-            exit(1);
+            virtio_error(vdev, "virtio-net ctrl missing headers");
+            return;
         }
 
         iov_cnt = elem->out_num;

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [Qemu-devel] [PATCH 4/7] virtio-net: handle virtio_net_receive() errors
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
                   ` (2 preceding siblings ...)
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error Greg Kurz
@ 2016-09-21 13:14 ` Greg Kurz
  2016-09-21 14:38   ` Cornelia Huck
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 5/7] virtio-net: handle virtio_net_flush_tx() errors Greg Kurz
                   ` (4 subsequent siblings)
  8 siblings, 1 reply; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:14 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

All these errors are caused by a buggy guest: let's switch the device to
the broken state instead of terminating QEMU.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/net/virtio-net.c |   25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 68a448acd81b..8f59402306eb 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1122,21 +1122,22 @@ static ssize_t virtio_net_receive(NetClientState *nc, const uint8_t *buf, size_t
 
         elem = virtqueue_pop(q->rx_vq, sizeof(VirtQueueElement));
         if (!elem) {
-            if (i == 0)
-                return -1;
-            error_report("virtio-net unexpected empty queue: "
-                         "i %zd mergeable %d offset %zd, size %zd, "
-                         "guest hdr len %zd, host hdr len %zd "
-                         "guest features 0x%" PRIx64,
-                         i, n->mergeable_rx_bufs, offset, size,
-                         n->guest_hdr_len, n->host_hdr_len,
-                         vdev->guest_features);
-            exit(1);
+            if (i) {
+                virtio_error(vdev, "virtio-net unexpected empty queue: "
+                             "i %zd mergeable %d offset %zd, size %zd, "
+                             "guest hdr len %zd, host hdr len %zd "
+                             "guest features 0x%" PRIx64,
+                             i, n->mergeable_rx_bufs, offset, size,
+                             n->guest_hdr_len, n->host_hdr_len,
+                             vdev->guest_features);
+            }
+            return -1;
         }
 
         if (elem->in_num < 1) {
-            error_report("virtio-net receive queue contains no in buffers");
-            exit(1);
+            virtio_error(vdev,
+                         "virtio-net receive queue contains no in buffers");
+            return -1;
         }
 
         sg = elem->in_sg;

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [Qemu-devel] [PATCH 5/7] virtio-net: handle virtio_net_flush_tx() errors
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
                   ` (3 preceding siblings ...)
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 4/7] virtio-net: handle virtio_net_receive() errors Greg Kurz
@ 2016-09-21 13:14 ` Greg Kurz
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 6/7] virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error() Greg Kurz
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:14 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

All these errors are caused by a buggy guest: let's switch the device to
the broken state instead of terminating QEMU.

If this happens, virtio_net_flush_tx() also returns -EINVAL, so that all
callers can stop processing the buggy request immediatly.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/net/virtio-net.c |   22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 8f59402306eb..958282838f57 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1239,15 +1239,15 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
         out_num = elem->out_num;
         out_sg = elem->out_sg;
         if (out_num < 1) {
-            error_report("virtio-net header not in first element");
-            exit(1);
+            virtio_error(vdev, "virtio-net header not in first element");
+            return -EINVAL;
         }
 
         if (n->has_vnet_hdr) {
             if (iov_to_buf(out_sg, out_num, 0, &mhdr, n->guest_hdr_len) <
                 n->guest_hdr_len) {
-                error_report("virtio-net header incorrect");
-                exit(1);
+                virtio_error(vdev, "virtio-net header incorrect");
+                return -EINVAL;
             }
             if (n->needs_vnet_hdr_swap) {
                 virtio_net_hdr_swap(vdev, (void *) &mhdr);
@@ -1315,7 +1315,9 @@ static void virtio_net_handle_tx_timer(VirtIODevice *vdev, VirtQueue *vq)
         virtio_queue_set_notification(vq, 1);
         timer_del(q->tx_timer);
         q->tx_waiting = 0;
-        virtio_net_flush_tx(q);
+        if (virtio_net_flush_tx(q) == -EINVAL) {
+            return;
+        }
     } else {
         timer_mod(q->tx_timer,
                        qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + n->tx_timeout);
@@ -1386,8 +1388,9 @@ static void virtio_net_tx_bh(void *opaque)
     }
 
     ret = virtio_net_flush_tx(q);
-    if (ret == -EBUSY) {
-        return; /* Notification re-enable handled by tx_complete */
+    if (ret == -EBUSY || ret == -EINVAL) {
+        return; /* Notification re-enable handled by tx_complete or device
+                 * broken */
     }
 
     /* If we flush a full burst of packets, assume there are
@@ -1402,7 +1405,10 @@ static void virtio_net_tx_bh(void *opaque)
      * anything that may have come in while we weren't looking.  If
      * we find something, assume the guest is still active and reschedule */
     virtio_queue_set_notification(q->tx_vq, 1);
-    if (virtio_net_flush_tx(q) > 0) {
+    ret = virtio_net_flush_tx(q);
+    if (ret == -EINVAL) {
+        return;
+    } else if (ret > 0) {
         virtio_queue_set_notification(q->tx_vq, 0);
         qemu_bh_schedule(q->tx_bh);
         q->tx_waiting = 1;

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [Qemu-devel] [PATCH 6/7] virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
                   ` (4 preceding siblings ...)
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 5/7] virtio-net: handle virtio_net_flush_tx() errors Greg Kurz
@ 2016-09-21 13:14 ` Greg Kurz
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 7/7] virtio-scsi: handle virtio_scsi_set_config() error Greg Kurz
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:14 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

All these errors are caused by a buggy guest: let's switch the device to
the broken state and stop processing the request, instead of terminating
QEMU.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/scsi/virtio-scsi.c |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index e596b6474131..d475d5e40d91 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -81,10 +81,9 @@ static void virtio_scsi_complete_req(VirtIOSCSIReq *req)
     virtio_scsi_free_req(req);
 }
 
-static void virtio_scsi_bad_req(void)
+static void virtio_scsi_bad_req(VirtIOSCSIReq *req)
 {
-    error_report("wrong size for virtio-scsi headers");
-    exit(1);
+    virtio_error(req->vdev, "wrong size for virtio-scsi headers");
 }
 
 static size_t qemu_sgl_concat(VirtIOSCSIReq *req, struct iovec *iov,
@@ -387,7 +386,7 @@ static void virtio_scsi_handle_ctrl_req(VirtIOSCSI *s, VirtIOSCSIReq *req)
 
     if (iov_to_buf(req->elem.out_sg, req->elem.out_num, 0,
                 &type, sizeof(type)) < sizeof(type)) {
-        virtio_scsi_bad_req();
+        virtio_scsi_bad_req(req);
         return;
     }
 
@@ -395,7 +394,8 @@ static void virtio_scsi_handle_ctrl_req(VirtIOSCSI *s, VirtIOSCSIReq *req)
     if (type == VIRTIO_SCSI_T_TMF) {
         if (virtio_scsi_parse_req(req, sizeof(VirtIOSCSICtrlTMFReq),
                     sizeof(VirtIOSCSICtrlTMFResp)) < 0) {
-            virtio_scsi_bad_req();
+            virtio_scsi_bad_req(req);
+            return;
         } else {
             r = virtio_scsi_do_tmf(s, req);
         }
@@ -404,7 +404,8 @@ static void virtio_scsi_handle_ctrl_req(VirtIOSCSI *s, VirtIOSCSIReq *req)
                type == VIRTIO_SCSI_T_AN_SUBSCRIBE) {
         if (virtio_scsi_parse_req(req, sizeof(VirtIOSCSICtrlANReq),
                     sizeof(VirtIOSCSICtrlANResp)) < 0) {
-            virtio_scsi_bad_req();
+            virtio_scsi_bad_req(req);
+            return;
         } else {
             req->resp.an.event_actual = 0;
             req->resp.an.response = VIRTIO_SCSI_S_OK;
@@ -708,7 +709,8 @@ void virtio_scsi_push_event(VirtIOSCSI *s, SCSIDevice *dev,
     }
 
     if (virtio_scsi_parse_req(req, 0, sizeof(VirtIOSCSIEvent))) {
-        virtio_scsi_bad_req();
+        virtio_scsi_bad_req(req);
+        goto out;
     }
 
     evt = &req->resp.event;

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [Qemu-devel] [PATCH 7/7] virtio-scsi: handle virtio_scsi_set_config() error
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
                   ` (5 preceding siblings ...)
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 6/7] virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error() Greg Kurz
@ 2016-09-21 13:14 ` Greg Kurz
  2016-09-21 13:35 ` [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination no-reply
  2016-09-22  1:19 ` Gonglei
  8 siblings, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:14 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Greg Kurz, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini

This error is caused by a buggy guest: let's switch the device to the
broken state instead of terminating QEMU.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/scsi/virtio-scsi.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index d475d5e40d91..592b6fd72359 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -628,8 +628,9 @@ static void virtio_scsi_set_config(VirtIODevice *vdev,
 
     if ((uint32_t) virtio_ldl_p(vdev, &scsiconf->sense_size) >= 65536 ||
         (uint32_t) virtio_ldl_p(vdev, &scsiconf->cdb_size) >= 256) {
-        error_report("bad data written to virtio-scsi configuration space");
-        exit(1);
+        virtio_error(vdev,
+                     "bad data written to virtio-scsi configuration space");
+        return;
     }
 
     vs->sense_size = virtio_ldl_p(vdev, &scsiconf->sense_size);

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
                   ` (6 preceding siblings ...)
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 7/7] virtio-scsi: handle virtio_scsi_set_config() error Greg Kurz
@ 2016-09-21 13:35 ` no-reply
  2016-09-21 13:44   ` Greg Kurz
  2016-09-22  1:19 ` Gonglei
  8 siblings, 1 reply; 34+ messages in thread
From: no-reply @ 2016-09-21 13:35 UTC (permalink / raw)
  To: groug
  Cc: famz, qemu-devel, kwolf, mst, jasowang, mreitz, aneesh.kumar,
	stefanha, cornelia.huck, pbonzini

Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 147446363181.4880.18104448248886932114.stgit@bahia
Subject: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
make J=8 docker-test-quick@centos6
make J=8 docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
4a3a53c virtio-scsi: handle virtio_scsi_set_config() error
7adf176 virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
91e13db virtio-net: handle virtio_net_flush_tx() errors
540249a virtio-net: handle virtio_net_receive() errors
6a9bfcf virtio-net: handle virtio_net_handle_ctrl() error
65c4f5e virtio-blk: handle virtio_blk_handle_request() errors
538cc03 virtio-9p: handle handle_9p_output() error

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD centos6
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPY RUNNER
  RUN test-quick in centos6
No C++ compiler available; disabling C++ specific optional code
Install prefix    /tmp/qemu-test/src/tests/docker/install
BIOS directory    /tmp/qemu-test/src/tests/docker/install/share/qemu
binary directory  /tmp/qemu-test/src/tests/docker/install/bin
library directory /tmp/qemu-test/src/tests/docker/install/lib
module directory  /tmp/qemu-test/src/tests/docker/install/lib/qemu
libexec directory /tmp/qemu-test/src/tests/docker/install/libexec
include directory /tmp/qemu-test/src/tests/docker/install/include
config directory  /tmp/qemu-test/src/tests/docker/install/etc
local state directory   /tmp/qemu-test/src/tests/docker/install/var
Manual directory  /tmp/qemu-test/src/tests/docker/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /tmp/qemu-test/src
C compiler        cc
Host C compiler   cc
C++ compiler      
Objective-C compiler cc
ARFLAGS           rv
CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -g 
QEMU_CFLAGS       -I/usr/include/pixman-1    -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make              make
install           install
python            python -B
smbd              /usr/sbin/smbd
module support    no
host CPU          x86_64
host big endian   no
target list       x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
pixman            system
SDL support       yes (1.2.14)
GTK support       no 
GTK GL support    no
VTE support       no 
TLS priority      NORMAL
GNUTLS support    no
GNUTLS rnd        no
libgcrypt         no
libgcrypt kdf     no
nettle            no 
nettle kdf        no
libtasn1          no
curses support    no
virgl support     no
curl support      no
mingw32 support   no
Audio drivers     oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS support    no
VNC support       yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support       no
brlapi support    no
bluez  support    no
Documentation     no
PIE               yes
vde support       no
netmap support    no
Linux AIO support no
ATTR/XATTR support yes
Install blobs     yes
KVM support       yes
RDMA support      no
TCG interpreter   no
fdt support       yes
preadv support    yes
fdatasync         yes
madvise           yes
posix_madvise     yes
uuid support      no
libcap-ng support no
vhost-net support yes
vhost-scsi support yes
vhost-vsock support yes
Trace backends    log
spice support     no 
rbd support       no
xfsctl support    no
smartcard support no
libusb            no
usb net redir     no
OpenGL support    no
OpenGL dmabufs    no
libiscsi support  no
libnfs support    no
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine pool    yes
GlusterFS support no
Archipelago support no
gcov              gcov
gcov enabled      no
TPM support       yes
libssh2 support   no
TPM passthrough   yes
QOM debugging     yes
vhdx              no
lzo support       no
snappy support    no
bzip2 support     no
NUMA host support no
tcmalloc support  no
jemalloc support  no
avx2 optimization no
replication support yes
  GEN   x86_64-softmmu/config-devices.mak.tmp
  GEN   aarch64-softmmu/config-devices.mak.tmp
  GEN   config-host.h
  GEN   qemu-options.def
  GEN   qmp-commands.h
  GEN   qapi-types.h
  GEN   qapi-visit.h
  GEN   qapi-event.h
  GEN   x86_64-softmmu/config-devices.mak
  GEN   aarch64-softmmu/config-devices.mak
  GEN   qmp-introspect.h
  GEN   tests/test-qapi-types.h
  GEN   tests/test-qapi-visit.h
  GEN   tests/test-qmp-commands.h
  GEN   tests/test-qapi-event.h
  GEN   tests/test-qmp-introspect.h
  GEN   config-all-devices.mak
  GEN   trace/generated-tracers.h
  GEN   trace/generated-events.h
  GEN   trace/generated-tcg-tracers.h
  GEN   trace/generated-helpers-wrappers.h
  GEN   trace/generated-helpers.h
  CC    tests/qemu-iotests/socket_scm_helper.o
  GEN   qga/qapi-generated/qga-qapi-types.h
  GEN   qga/qapi-generated/qga-qapi-visit.h
  GEN   qga/qapi-generated/qga-qmp-commands.h
  GEN   qga/qapi-generated/qga-qapi-types.c
  GEN   qga/qapi-generated/qga-qapi-visit.c
  GEN   qga/qapi-generated/qga-qmp-marshal.c
  GEN   qmp-introspect.c
  GEN   qapi-types.c
  GEN   qapi-visit.c
  GEN   qapi-event.c
  CC    qapi/qapi-visit-core.o
  CC    qapi/qapi-dealloc-visitor.o
  CC    qapi/qmp-input-visitor.o
  CC    qapi/qmp-output-visitor.o
  CC    qapi/qmp-registry.o
  CC    qapi/qmp-dispatch.o
  CC    qapi/string-input-visitor.o
  CC    qapi/string-output-visitor.o
  CC    qapi/opts-visitor.o
  CC    qapi/qapi-clone-visitor.o
  CC    qapi/qmp-event.o
  CC    qapi/qapi-util.o
  CC    qobject/qnull.o
  CC    qobject/qint.o
  CC    qobject/qstring.o
  CC    qobject/qdict.o
  CC    qobject/qlist.o
  CC    qobject/qfloat.o
  CC    qobject/qbool.o
  CC    qobject/qjson.o
  CC    qobject/qobject.o
  CC    qobject/json-lexer.o
  CC    qobject/json-streamer.o
  CC    qobject/json-parser.o
  GEN   trace/generated-events.c
  CC    trace/control.o
  CC    trace/qmp.o
  CC    util/osdep.o
  CC    util/cutils.o
  CC    util/unicode.o
  CC    util/qemu-timer-common.o
  CC    util/bufferiszero.o
  CC    util/compatfd.o
  CC    util/event_notifier-posix.o
  CC    util/mmap-alloc.o
  CC    util/oslib-posix.o
  CC    util/qemu-openpty.o
  CC    util/qemu-thread-posix.o
  CC    util/memfd.o
  CC    util/envlist.o
  CC    util/path.o
  CC    util/module.o
  CC    util/bitmap.o
  CC    util/bitops.o
  CC    util/hbitmap.o
  CC    util/acl.o
  CC    util/fifo8.o
  CC    util/error.o
  CC    util/qemu-error.o
  CC    util/id.o
  CC    util/iov.o
  CC    util/qemu-config.o
  CC    util/uri.o
  CC    util/qemu-sockets.o
  CC    util/notify.o
  CC    util/qemu-option.o
  CC    util/qemu-progress.o
  CC    util/hexdump.o
  CC    util/crc32c.o
  CC    util/throttle.o
  CC    util/getauxval.o
  CC    util/readline.o
  CC    util/rfifolock.o
  CC    util/rcu.o
  CC    util/qemu-coroutine.o
  CC    util/qemu-coroutine-lock.o
  CC    util/qemu-coroutine-io.o
  CC    util/qemu-coroutine-sleep.o
  CC    util/coroutine-ucontext.o
  CC    util/timed-average.o
  CC    util/buffer.o
  CC    util/base64.o
  CC    util/log.o
  CC    util/qdist.o
  CC    util/qht.o
/tmp/qemu-test/src/util/qht.c: In function ‘qht_reset_size’:
/tmp/qemu-test/src/util/qht.c:413: warning: ‘new’ may be used uninitialized in this function
  CC    util/range.o
  CC    crypto/pbkdf-stub.o
  CC    stubs/arch-query-cpu-def.o
  CC    stubs/arch-query-cpu-model-expansion.o
  CC    stubs/arch-query-cpu-model-comparison.o
  CC    stubs/arch-query-cpu-model-baseline.o
  CC    stubs/bdrv-next-monitor-owned.o
  CC    stubs/blk-commit-all.o
  CC    stubs/blockdev-close-all-bdrv-states.o
  CC    stubs/clock-warp.o
  CC    stubs/cpu-get-clock.o
  CC    stubs/cpu-get-icount.o
  CC    stubs/dump.o
  CC    stubs/fdset-add-fd.o
  CC    stubs/fdset-get-fd.o
  CC    stubs/fdset-find-fd.o
  CC    stubs/fdset-remove-fd.o
  CC    stubs/gdbstub.o
  CC    stubs/get-fd.o
  CC    stubs/get-next-serial.o
  CC    stubs/get-vm-name.o
  CC    stubs/iothread-lock.o
  CC    stubs/is-daemonized.o
  CC    stubs/machine-init-done.o
  CC    stubs/migr-blocker.o
  CC    stubs/mon-is-qmp.o
  CC    stubs/mon-printf.o
  CC    stubs/monitor-init.o
  CC    stubs/notify-event.o
  CC    stubs/qtest.o
  CC    stubs/replay.o
  CC    stubs/reset.o
  CC    stubs/replay-user.o
  CC    stubs/runstate-check.o
  CC    stubs/set-fd-handler.o
  CC    stubs/slirp.o
  CC    stubs/sysbus.o
  CC    stubs/trace-control.o
  CC    stubs/uuid.o
  CC    stubs/vm-stop.o
  CC    stubs/vmstate.o
  CC    stubs/cpus.o
  CC    stubs/kvm.o
  CC    stubs/qmp_pc_dimm_device_list.o
  CC    stubs/target-monitor-defs.o
  CC    stubs/target-get-monitor-def.o
  CC    stubs/vhost.o
  CC    stubs/iohandler.o
  CC    stubs/smbios_type_38.o
  CC    stubs/pc_madt_cpu_entry.o
  CC    stubs/ipmi.o
  CC    contrib/ivshmem-client/ivshmem-client.o
  CC    contrib/ivshmem-client/main.o
  CC    contrib/ivshmem-server/ivshmem-server.o
  CC    contrib/ivshmem-server/main.o
  CC    qemu-nbd.o
  CC    async.o
  CC    thread-pool.o
  CC    block.o
  CC    blockjob.o
  CC    main-loop.o
  CC    iohandler.o
  CC    qemu-timer.o
  CC    aio-posix.o
  CC    qemu-io-cmds.o
  CC    replication.o
  CC    block/raw_bsd.o
  CC    block/qcow.o
  CC    block/vdi.o
  CC    block/vmdk.o
  CC    block/cloop.o
  CC    block/bochs.o
  CC    block/vpc.o
  CC    block/vvfat.o
  CC    block/qcow2.o
  CC    block/qcow2-refcount.o
  CC    block/qcow2-cluster.o
  CC    block/qcow2-snapshot.o
  CC    block/qcow2-cache.o
  CC    block/qed.o
  CC    block/qed-gencb.o
  CC    block/qed-l2-cache.o
  CC    block/qed-table.o
  CC    block/qed-cluster.o
  CC    block/qed-check.o
  CC    block/quorum.o
  CC    block/parallels.o
  CC    block/blkdebug.o
  CC    block/blkverify.o
  CC    block/blkreplay.o
  CC    block/block-backend.o
  CC    block/snapshot.o
  CC    block/qapi.o
  CC    block/raw-posix.o
  CC    block/null.o
  CC    block/mirror.o
  CC    block/commit.o
  CC    block/io.o
  CC    block/throttle-groups.o
  CC    block/nbd.o
  CC    block/nbd-client.o
  CC    block/sheepdog.o
  CC    block/accounting.o
  CC    block/dirty-bitmap.o
  CC    block/write-threshold.o
  CC    block/backup.o
  CC    block/replication.o
  CC    block/crypto.o
  CC    nbd/server.o
  CC    nbd/client.o
  CC    nbd/common.o
  CC    block/dmg.o
  CC    crypto/init.o
  CC    crypto/hash.o
  CC    crypto/hash-glib.o
  CC    crypto/aes.o
  CC    crypto/desrfb.o
  CC    crypto/cipher.o
  CC    crypto/tlscreds.o
  CC    crypto/tlscredsanon.o
  CC    crypto/tlscredsx509.o
  CC    crypto/tlssession.o
  CC    crypto/secret.o
  CC    crypto/random-platform.o
  CC    crypto/pbkdf.o
  CC    crypto/ivgen.o
  CC    crypto/ivgen-essiv.o
  CC    crypto/ivgen-plain.o
  CC    crypto/ivgen-plain64.o
  CC    crypto/afsplit.o
  CC    crypto/xts.o
  CC    crypto/block.o
  CC    crypto/block-qcow.o
  CC    crypto/block-luks.o
  CC    io/channel.o
  CC    io/channel-buffer.o
  CC    io/channel-command.o
  CC    io/channel-file.o
  CC    io/channel-socket.o
  CC    io/channel-tls.o
  CC    io/channel-watch.o
  CC    io/channel-websock.o
  CC    io/channel-util.o
  CC    io/task.o
  CC    qom/object.o
  CC    qom/container.o
  CC    qom/qom-qobject.o
  CC    qom/object_interfaces.o
  GEN   qemu-img-cmds.h
  CC    qemu-io.o
  CC    qemu-bridge-helper.o
  CC    blockdev.o
  CC    blockdev-nbd.o
  CC    iothread.o
  CC    qdev-monitor.o
  CC    device-hotplug.o
  CC    os-posix.o
  CC    qemu-char.o
  CC    page_cache.o
  CC    accel.o
  CC    bt-host.o
  CC    bt-vhci.o
  CC    dma-helpers.o
  CC    vl.o
  CC    tpm.o
  CC    device_tree.o
  GEN   qmp-marshal.c
  CC    qmp.o
  CC    hmp.o
  CC    tcg-runtime.o
  CC    audio/audio.o
  CC    audio/noaudio.o
  CC    audio/wavaudio.o
  CC    audio/mixeng.o
  CC    audio/sdlaudio.o
  CC    audio/ossaudio.o
  CC    audio/wavcapture.o
  CC    backends/rng.o
  CC    backends/rng-egd.o
  CC    backends/rng-random.o
  CC    backends/msmouse.o
  CC    backends/testdev.o
  CC    backends/tpm.o
  CC    backends/hostmem.o
  CC    backends/hostmem-ram.o
  CC    backends/hostmem-file.o
  CC    block/stream.o
  CC    disas/arm.o
  CC    disas/i386.o
  CC    fsdev/qemu-fsdev-dummy.o
  CC    hw/acpi/core.o
  CC    fsdev/qemu-fsdev-opts.o
  CC    hw/acpi/piix4.o
  CC    hw/acpi/pcihp.o
  CC    hw/acpi/ich9.o
  CC    hw/acpi/tco.o
  CC    hw/acpi/cpu_hotplug.o
  CC    hw/acpi/memory_hotplug.o
  CC    hw/acpi/memory_hotplug_acpi_table.o
  CC    hw/acpi/cpu.o
  CC    hw/acpi/acpi_interface.o
  CC    hw/acpi/bios-linker-loader.o
  CC    hw/acpi/aml-build.o
  CC    hw/acpi/ipmi.o
  CC    hw/audio/sb16.o
  CC    hw/audio/es1370.o
  CC    hw/audio/ac97.o
  CC    hw/audio/fmopl.o
  CC    hw/audio/adlib.o
  CC    hw/audio/gus.o
  CC    hw/audio/gusemu_hal.o
  CC    hw/audio/gusemu_mixer.o
  CC    hw/audio/cs4231a.o
  CC    hw/audio/intel-hda.o
  CC    hw/audio/hda-codec.o
  CC    hw/audio/pcspk.o
  CC    hw/audio/wm8750.o
  CC    hw/audio/pl041.o
  CC    hw/audio/lm4549.o
  CC    hw/audio/marvell_88w8618.o
  CC    hw/block/block.o
  CC    hw/block/cdrom.o
  CC    hw/block/hd-geometry.o
  CC    hw/block/fdc.o
  CC    hw/block/m25p80.o
  CC    hw/block/nand.o
  CC    hw/block/pflash_cfi01.o
  CC    hw/block/pflash_cfi02.o
  CC    hw/block/onenand.o
  CC    hw/block/ecc.o
  CC    hw/block/nvme.o
  CC    hw/bt/core.o
  CC    hw/bt/l2cap.o
  CC    hw/bt/sdp.o
  CC    hw/bt/hci.o
  CC    hw/bt/hid.o
  CC    hw/bt/hci-csr.o
  CC    hw/char/ipoctal232.o
  CC    hw/char/parallel.o
  CC    hw/char/pl011.o
  CC    hw/char/serial.o
  CC    hw/char/serial-isa.o
  CC    hw/char/serial-pci.o
  CC    hw/char/virtio-console.o
  CC    hw/char/cadence_uart.o
  CC    hw/char/debugcon.o
  CC    hw/char/imx_serial.o
  CC    hw/core/qdev.o
  CC    hw/core/qdev-properties.o
  CC    hw/core/bus.o
  CC    hw/core/fw-path-provider.o
  CC    hw/core/irq.o
  CC    hw/core/hotplug.o
  CC    hw/core/ptimer.o
  CC    hw/core/sysbus.o
  CC    hw/core/machine.o
  CC    hw/core/null-machine.o
  CC    hw/core/loader.o
  CC    hw/core/qdev-properties-system.o
  CC    hw/core/register.o
  CC    hw/core/platform-bus.o
  CC    hw/display/ads7846.o
  CC    hw/display/cirrus_vga.o
  CC    hw/display/pl110.o
  CC    hw/display/ssd0303.o
  CC    hw/display/vga-pci.o
  CC    hw/display/ssd0323.o
  CC    hw/display/vga-isa.o
  CC    hw/display/vmware_vga.o
  CC    hw/display/blizzard.o
  CC    hw/display/exynos4210_fimd.o
  CC    hw/display/framebuffer.o
  CC    hw/display/tc6393xb.o
  CC    hw/dma/pl080.o
  CC    hw/dma/pl330.o
  CC    hw/dma/i8257.o
  CC    hw/dma/xlnx-zynq-devcfg.o
  CC    hw/gpio/max7310.o
  CC    hw/gpio/pl061.o
  CC    hw/gpio/zaurus.o
  CC    hw/gpio/gpio_key.o
  CC    hw/i2c/core.o
  CC    hw/i2c/smbus.o
  CC    hw/i2c/smbus_eeprom.o
  CC    hw/i2c/i2c-ddc.o
  CC    hw/i2c/versatile_i2c.o
  CC    hw/i2c/smbus_ich9.o
  CC    hw/i2c/pm_smbus.o
  CC    hw/i2c/bitbang_i2c.o
  CC    hw/i2c/exynos4210_i2c.o
  CC    hw/i2c/imx_i2c.o
  CC    hw/i2c/aspeed_i2c.o
  CC    hw/ide/core.o
  CC    hw/ide/atapi.o
  CC    hw/ide/qdev.o
  CC    hw/ide/pci.o
  CC    hw/ide/isa.o
  CC    hw/ide/piix.o
  CC    hw/ide/microdrive.o
  CC    hw/ide/ahci.o
  CC    hw/ide/ich.o
  CC    hw/input/hid.o
  CC    hw/input/lm832x.o
  CC    hw/input/pckbd.o
  CC    hw/input/pl050.o
  CC    hw/input/ps2.o
  CC    hw/input/stellaris_input.o
  CC    hw/input/tsc2005.o
  CC    hw/input/vmmouse.o
  CC    hw/input/virtio-input.o
  CC    hw/input/virtio-input-hid.o
  CC    hw/input/virtio-input-host.o
  CC    hw/intc/i8259_common.o
  CC    hw/intc/i8259.o
  CC    hw/intc/pl190.o
  CC    hw/intc/imx_avic.o
  CC    hw/intc/realview_gic.o
  CC    hw/intc/ioapic_common.o
  CC    hw/intc/arm_gic_common.o
  CC    hw/intc/arm_gic.o
  CC    hw/intc/arm_gicv2m.o
  CC    hw/intc/arm_gicv3_common.o
  CC    hw/intc/arm_gicv3.o
  CC    hw/intc/arm_gicv3_dist.o
  CC    hw/intc/arm_gicv3_redist.o
  CC    hw/ipack/ipack.o
  CC    hw/ipack/tpci200.o
  CC    hw/ipmi/ipmi.o
  CC    hw/ipmi/ipmi_bmc_sim.o
  CC    hw/ipmi/ipmi_bmc_extern.o
  CC    hw/ipmi/isa_ipmi_kcs.o
  CC    hw/ipmi/isa_ipmi_bt.o
  CC    hw/isa/isa-bus.o
  CC    hw/isa/apm.o
  CC    hw/mem/pc-dimm.o
  CC    hw/mem/nvdimm.o
  CC    hw/misc/applesmc.o
  CC    hw/misc/max111x.o
  CC    hw/misc/tmp105.o
  CC    hw/misc/debugexit.o
  CC    hw/misc/sga.o
  CC    hw/misc/pc-testdev.o
  CC    hw/misc/pci-testdev.o
  CC    hw/misc/arm_l2x0.o
  CC    hw/misc/arm_integrator_debug.o
  CC    hw/misc/a9scu.o
  CC    hw/misc/arm11scu.o
  CC    hw/net/ne2000.o
  CC    hw/net/eepro100.o
  CC    hw/net/pcnet-pci.o
  CC    hw/net/pcnet.o
  CC    hw/net/e1000.o
  CC    hw/net/e1000x_common.o
  CC    hw/net/net_tx_pkt.o
  CC    hw/net/net_rx_pkt.o
  CC    hw/net/e1000e.o
  CC    hw/net/e1000e_core.o
  CC    hw/net/rtl8139.o
  CC    hw/net/vmxnet3.o
  CC    hw/net/smc91c111.o
  CC    hw/net/lan9118.o
  CC    hw/net/ne2000-isa.o
  CC    hw/net/xgmac.o
  CC    hw/net/allwinner_emac.o
  CC    hw/net/imx_fec.o
  CC    hw/net/cadence_gem.o
  CC    hw/net/stellaris_enet.o
  CC    hw/net/rocker/rocker.o
  CC    hw/net/rocker/rocker_fp.o
  CC    hw/net/rocker/rocker_desc.o
  CC    hw/net/rocker/rocker_world.o
  CC    hw/net/rocker/rocker_of_dpa.o
  CC    hw/nvram/eeprom93xx.o
  CC    hw/nvram/fw_cfg.o
  CC    hw/pci-bridge/pci_bridge_dev.o
  CC    hw/pci-bridge/pci_expander_bridge.o
  CC    hw/pci-bridge/xio3130_upstream.o
  CC    hw/pci-bridge/xio3130_downstream.o
  CC    hw/pci-bridge/ioh3420.o
  CC    hw/pci-bridge/i82801b11.o
  CC    hw/pci-host/pam.o
  CC    hw/pci-host/versatile.o
  CC    hw/pci-host/piix.o
  CC    hw/pci-host/q35.o
  CC    hw/pci-host/gpex.o
  CC    hw/pci/pci.o
  CC    hw/pci/pci_bridge.o
  CC    hw/pci/msix.o
  CC    hw/pci/msi.o
  CC    hw/pci/shpc.o
  CC    hw/pci/slotid_cap.o
  CC    hw/pci/pci_host.o
  CC    hw/pci/pcie_host.o
  CC    hw/pci/pcie.o
  CC    hw/pci/pcie_aer.o
  CC    hw/pci/pcie_port.o
  CC    hw/pci/pci-stub.o
  CC    hw/pcmcia/pcmcia.o
  CC    hw/scsi/scsi-disk.o
  CC    hw/scsi/scsi-generic.o
  CC    hw/scsi/scsi-bus.o
  CC    hw/scsi/lsi53c895a.o
  CC    hw/scsi/mptsas.o
/tmp/qemu-test/src/hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’:
/tmp/qemu-test/src/hw/nvram/fw_cfg.c:330: warning: ‘read’ may be used uninitialized in this function
  CC    hw/scsi/mptconfig.o
  CC    hw/scsi/mptendian.o
  CC    hw/scsi/megasas.o
  CC    hw/scsi/vmw_pvscsi.o
  CC    hw/scsi/esp.o
  CC    hw/scsi/esp-pci.o
  CC    hw/sd/pl181.o
  CC    hw/sd/ssi-sd.o
  CC    hw/sd/sd.o
  CC    hw/sd/core.o
  CC    hw/sd/sdhci.o
  CC    hw/smbios/smbios.o
  CC    hw/smbios/smbios_type_38.o
  CC    hw/ssi/pl022.o
  CC    hw/ssi/ssi.o
  CC    hw/ssi/xilinx_spips.o
  CC    hw/ssi/aspeed_smc.o
  CC    hw/timer/arm_timer.o
  CC    hw/timer/arm_mptimer.o
  CC    hw/timer/a9gtimer.o
  CC    hw/timer/cadence_ttc.o
  CC    hw/timer/ds1338.o
  CC    hw/timer/hpet.o
  CC    hw/timer/i8254_common.o
  CC    hw/timer/i8254.o
  CC    hw/timer/pl031.o
  CC    hw/timer/twl92230.o
  CC    hw/timer/imx_epit.o
  CC    hw/timer/imx_gpt.o
  CC    hw/timer/stm32f2xx_timer.o
  CC    hw/timer/aspeed_timer.o
  CC    hw/tpm/tpm_tis.o
  CC    hw/tpm/tpm_passthrough.o
  CC    hw/tpm/tpm_util.o
  CC    hw/usb/core.o
  CC    hw/usb/combined-packet.o
  CC    hw/usb/bus.o
  CC    hw/usb/libhw.o
  CC    hw/usb/desc.o
  CC    hw/usb/desc-msos.o
  CC    hw/usb/hcd-uhci.o
  CC    hw/usb/hcd-ohci.o
  CC    hw/usb/hcd-ehci.o
  CC    hw/usb/hcd-ehci-pci.o
  CC    hw/usb/hcd-ehci-sysbus.o
  CC    hw/usb/hcd-xhci.o
  CC    hw/usb/hcd-musb.o
  CC    hw/usb/dev-hub.o
  CC    hw/usb/dev-hid.o
  CC    hw/usb/dev-wacom.o
  CC    hw/usb/dev-storage.o
  CC    hw/usb/dev-uas.o
  CC    hw/usb/dev-audio.o
  CC    hw/usb/dev-serial.o
  CC    hw/usb/dev-network.o
  CC    hw/usb/dev-bluetooth.o
  CC    hw/usb/dev-smartcard-reader.o
  CC    hw/usb/dev-mtp.o
  CC    hw/usb/host-stub.o
  CC    hw/virtio/virtio-rng.o
  CC    hw/virtio/virtio-pci.o
  CC    hw/virtio/virtio-bus.o
  CC    hw/virtio/virtio-mmio.o
  CC    hw/watchdog/watchdog.o
  CC    hw/watchdog/wdt_i6300esb.o
  CC    hw/watchdog/wdt_ib700.o
  CC    migration/migration.o
  CC    migration/socket.o
  CC    migration/fd.o
  CC    migration/exec.o
  CC    migration/tls.o
  CC    migration/vmstate.o
  CC    migration/qemu-file.o
  CC    migration/qemu-file-channel.o
  CC    migration/xbzrle.o
  CC    migration/postcopy-ram.o
  CC    migration/qjson.o
  CC    migration/block.o
  CC    net/net.o
  CC    net/queue.o
  CC    net/checksum.o
  CC    net/util.o
  CC    net/hub.o
  CC    net/socket.o
  CC    net/dump.o
  CC    net/eth.o
  CC    net/l2tpv3.o
  CC    net/tap.o
  CC    net/vhost-user.o
  CC    net/tap-linux.o
  CC    net/slirp.o
  CC    net/filter.o
  CC    net/filter-buffer.o
  CC    net/filter-mirror.o
  CC    qom/cpu.o
  CC    replay/replay.o
  CC    replay/replay-internal.o
  CC    replay/replay-events.o
  CC    replay/replay-time.o
  CC    replay/replay-input.o
  CC    replay/replay-char.o
  CC    slirp/cksum.o
  CC    slirp/if.o
  CC    slirp/ip6_icmp.o
  CC    slirp/ip_icmp.o
  CC    slirp/ip6_input.o
  CC    slirp/ip6_output.o
  CC    slirp/ip_input.o
  CC    slirp/ip_output.o
  CC    slirp/dnssearch.o
  CC    slirp/dhcpv6.o
  CC    slirp/slirp.o
  CC    slirp/mbuf.o
  CC    slirp/misc.o
  CC    slirp/sbuf.o
  CC    slirp/socket.o
  CC    slirp/tcp_input.o
  CC    slirp/tcp_output.o
  CC    slirp/tcp_subr.o
  CC    slirp/tcp_timer.o
  CC    slirp/udp.o
  CC    slirp/udp6.o
  CC    slirp/bootp.o
/tmp/qemu-test/src/slirp/tcp_input.c: In function ‘tcp_input’:
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_p’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_len’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_tos’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_id’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_off’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_ttl’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_sum’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_src.s_addr’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_dst.s_addr’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:220: warning: ‘save_ip6.ip_nh’ may be used uninitialized in this function
  CC    slirp/tftp.o
  CC    slirp/arp_table.o
  CC    slirp/ndp_table.o
  CC    ui/keymaps.o
  CC    ui/console.o
  CC    ui/cursor.o
  CC    ui/qemu-pixman.o
  CC    ui/input.o
  CC    ui/input-keymap.o
  CC    ui/input-legacy.o
  CC    ui/input-linux.o
  CC    ui/sdl.o
  CC    ui/sdl_zoom.o
/tmp/qemu-test/src/replay/replay-internal.c: In function ‘replay_put_array’:
/tmp/qemu-test/src/replay/replay-internal.c:68: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
  CC    ui/x_keymap.o
  CC    ui/vnc.o
  CC    ui/vnc-enc-zlib.o
  CC    ui/vnc-enc-hextile.o
  CC    ui/vnc-enc-tight.o
  CC    ui/vnc-palette.o
  CC    ui/vnc-enc-zrle.o
  CC    ui/vnc-auth-vencrypt.o
  CC    ui/vnc-ws.o
  CC    ui/vnc-jobs.o
  LINK  tests/qemu-iotests/socket_scm_helper
  CC    qga/commands.o
  CC    qga/guest-agent-command-state.o
  CC    qga/main.o
  CC    qga/commands-posix.o
  CC    qga/channel-posix.o
  CC    qga/qapi-generated/qga-qapi-types.o
  CC    qga/qapi-generated/qga-qapi-visit.o
  CC    qga/qapi-generated/qga-qmp-marshal.o
  CC    qmp-introspect.o
  CC    qapi-types.o
  CC    qapi-visit.o
  CC    qapi-event.o
  AR    libqemustub.a
  CC    qemu-img.o
  CC    qmp-marshal.o
  CC    trace/generated-events.o
  AS    optionrom/multiboot.o
  AS    optionrom/linuxboot.o
  CC    optionrom/linuxboot_dma.o
  AS    optionrom/kvmvapic.o
cc: unrecognized option '-no-integrated-as'
cc: unrecognized option '-no-integrated-as'
  Building optionrom/multiboot.img
  Building optionrom/linuxboot_dma.img
  Building optionrom/linuxboot.img
  Building optionrom/kvmvapic.img
  Building optionrom/multiboot.raw
  Building optionrom/linuxboot.raw
  Building optionrom/linuxboot_dma.raw
  AR    libqemuutil.a
  Building optionrom/kvmvapic.raw
  Signing optionrom/linuxboot.bin
  Signing optionrom/multiboot.bin
  Signing optionrom/linuxboot_dma.bin
  Signing optionrom/kvmvapic.bin
  LINK  qemu-ga
  LINK  ivshmem-client
  LINK  ivshmem-server
  LINK  qemu-nbd
  LINK  qemu-img
  LINK  qemu-io
  LINK  qemu-bridge-helper
  GEN   x86_64-softmmu/hmp-commands.h
  GEN   x86_64-softmmu/hmp-commands-info.h
  GEN   x86_64-softmmu/config-target.h
  CC    x86_64-softmmu/exec.o
  CC    x86_64-softmmu/cpu-exec.o
  CC    x86_64-softmmu/translate-all.o
  CC    x86_64-softmmu/translate-common.o
  CC    x86_64-softmmu/tcg/tcg-op.o
  CC    x86_64-softmmu/cpu-exec-common.o
  CC    x86_64-softmmu/tcg/tcg.o
  GEN   aarch64-softmmu/hmp-commands.h
  CC    x86_64-softmmu/tcg/optimize.o
  CC    x86_64-softmmu/tcg/tcg-common.o
  CC    x86_64-softmmu/fpu/softfloat.o
  CC    x86_64-softmmu/disas.o
  GEN   aarch64-softmmu/hmp-commands-info.h
  CC    x86_64-softmmu/arch_init.o
  CC    x86_64-softmmu/cpus.o
  CC    x86_64-softmmu/monitor.o
  GEN   aarch64-softmmu/config-target.h
  CC    x86_64-softmmu/gdbstub.o
  CC    aarch64-softmmu/exec.o
  CC    x86_64-softmmu/balloon.o
  CC    aarch64-softmmu/translate-all.o
  CC    aarch64-softmmu/cpu-exec.o
  CC    x86_64-softmmu/ioport.o
  CC    aarch64-softmmu/translate-common.o
  CC    x86_64-softmmu/numa.o
  CC    aarch64-softmmu/cpu-exec-common.o
  CC    x86_64-softmmu/qtest.o
  CC    aarch64-softmmu/tcg/tcg.o
  CC    x86_64-softmmu/bootdevice.o
  CC    aarch64-softmmu/tcg/tcg-op.o
  CC    x86_64-softmmu/kvm-all.o
  CC    x86_64-softmmu/memory.o
  CC    x86_64-softmmu/cputlb.o
  CC    x86_64-softmmu/memory_mapping.o
  CC    aarch64-softmmu/tcg/optimize.o
  CC    x86_64-softmmu/dump.o
  CC    aarch64-softmmu/tcg/tcg-common.o
  CC    x86_64-softmmu/migration/ram.o
  CC    aarch64-softmmu/fpu/softfloat.o
  CC    aarch64-softmmu/disas.o
  CC    x86_64-softmmu/migration/savevm.o
  CC    x86_64-softmmu/xen-common-stub.o
  CC    x86_64-softmmu/xen-hvm-stub.o
  CC    x86_64-softmmu/hw/acpi/nvdimm.o
  GEN   aarch64-softmmu/gdbstub-xml.c
  CC    x86_64-softmmu/hw/block/virtio-blk.o
  CC    x86_64-softmmu/hw/block/dataplane/virtio-blk.o
  CC    x86_64-softmmu/hw/char/virtio-serial-bus.o
  CC    x86_64-softmmu/hw/core/nmi.o
  CC    x86_64-softmmu/hw/cpu/core.o
  CC    x86_64-softmmu/hw/display/vga.o
  CC    aarch64-softmmu/kvm-stub.o
  CC    aarch64-softmmu/arch_init.o
  CC    x86_64-softmmu/hw/display/virtio-gpu.o
  CC    aarch64-softmmu/cpus.o
  CC    x86_64-softmmu/hw/display/virtio-gpu-3d.o
  CC    x86_64-softmmu/hw/display/virtio-gpu-pci.o
  CC    aarch64-softmmu/monitor.o
  CC    x86_64-softmmu/hw/display/virtio-vga.o
  CC    x86_64-softmmu/hw/intc/apic.o
  CC    x86_64-softmmu/hw/intc/apic_common.o
  CC    aarch64-softmmu/gdbstub.o
  CC    aarch64-softmmu/balloon.o
  CC    x86_64-softmmu/hw/intc/ioapic.o
  CC    aarch64-softmmu/ioport.o
  CC    aarch64-softmmu/numa.o
  CC    aarch64-softmmu/qtest.o
  CC    aarch64-softmmu/bootdevice.o
  CC    x86_64-softmmu/hw/isa/lpc_ich9.o
  CC    aarch64-softmmu/memory.o
  CC    aarch64-softmmu/cputlb.o
  CC    x86_64-softmmu/hw/misc/vmport.o
  CC    x86_64-softmmu/hw/misc/ivshmem.o
  CC    x86_64-softmmu/hw/misc/pvpanic.o
  CC    x86_64-softmmu/hw/misc/edu.o
  CC    x86_64-softmmu/hw/misc/hyperv_testdev.o
  CC    x86_64-softmmu/hw/net/virtio-net.o
  CC    x86_64-softmmu/hw/net/vhost_net.o
  CC    x86_64-softmmu/hw/scsi/virtio-scsi.o
  CC    aarch64-softmmu/memory_mapping.o
  CC    x86_64-softmmu/hw/scsi/virtio-scsi-dataplane.o
  CC    x86_64-softmmu/hw/scsi/vhost-scsi.o
  CC    aarch64-softmmu/dump.o
  CC    aarch64-softmmu/migration/ram.o
  CC    x86_64-softmmu/hw/timer/mc146818rtc.o
  CC    x86_64-softmmu/hw/vfio/common.o
  CC    aarch64-softmmu/migration/savevm.o
  CC    aarch64-softmmu/xen-common-stub.o
  CC    x86_64-softmmu/hw/vfio/pci.o
/tmp/qemu-test/src/hw/block/virtio-blk.c:471: error: conflicting types for ‘virtio_blk_handle_request’
/tmp/qemu-test/src/include/hw/virtio/virtio-blk.h:87: note: previous declaration of ‘virtio_blk_handle_request’ was here
/tmp/qemu-test/src/hw/block/virtio-blk.c: In function ‘virtio_blk_handle_request’:
/tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: implicit declaration of function ‘virtio_error’
/tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: nested extern declaration of ‘virtio_error’
make[1]: *** [hw/block/virtio-blk.o] Error 1
make[1]: *** Waiting for unfinished jobs....
  CC    aarch64-softmmu/xen-hvm-stub.o
  CC    aarch64-softmmu/hw/block/virtio-blk.o
  CC    aarch64-softmmu/hw/block/dataplane/virtio-blk.o
  CC    aarch64-softmmu/hw/char/exynos4210_uart.o
  CC    aarch64-softmmu/hw/char/omap_uart.o
  CC    aarch64-softmmu/hw/char/digic-uart.o
  CC    aarch64-softmmu/hw/char/stm32f2xx_usart.o
  CC    aarch64-softmmu/hw/char/bcm2835_aux.o
  CC    aarch64-softmmu/hw/char/virtio-serial-bus.o
  CC    aarch64-softmmu/hw/core/nmi.o
  CC    aarch64-softmmu/hw/cpu/arm11mpcore.o
  CC    aarch64-softmmu/hw/cpu/realview_mpcore.o
  CC    aarch64-softmmu/hw/cpu/a9mpcore.o
  CC    aarch64-softmmu/hw/cpu/a15mpcore.o
  CC    aarch64-softmmu/hw/cpu/core.o
  CC    aarch64-softmmu/hw/display/omap_dss.o
  CC    aarch64-softmmu/hw/display/omap_lcdc.o
  CC    aarch64-softmmu/hw/display/pxa2xx_lcd.o
  CC    aarch64-softmmu/hw/display/bcm2835_fb.o
  CC    aarch64-softmmu/hw/display/vga.o
  CC    aarch64-softmmu/hw/display/virtio-gpu.o
  CC    aarch64-softmmu/hw/display/virtio-gpu-3d.o
  CC    aarch64-softmmu/hw/display/virtio-gpu-pci.o
/tmp/qemu-test/src/hw/scsi/virtio-scsi.c: In function ‘virtio_scsi_bad_req’:
/tmp/qemu-test/src/hw/scsi/virtio-scsi.c:86: warning: implicit declaration of function ‘virtio_error’
/tmp/qemu-test/src/hw/scsi/virtio-scsi.c:86: warning: nested extern declaration of ‘virtio_error’
/tmp/qemu-test/src/hw/scsi/virtio-scsi.c:86: error: ‘VirtIOSCSIReq’ has no member named ‘vdev’
/tmp/qemu-test/src/hw/scsi/virtio-scsi.c: In function ‘virtio_scsi_handle_cmd_req_prepare’:
/tmp/qemu-test/src/hw/scsi/virtio-scsi.c:537: error: too few arguments to function ‘virtio_scsi_bad_req’
make[1]: *** [hw/scsi/virtio-scsi.o] Error 1
  CC    aarch64-softmmu/hw/display/dpcd.o
  CC    aarch64-softmmu/hw/display/xlnx_dp.o
  CC    aarch64-softmmu/hw/dma/xlnx_dpdma.o
  CC    aarch64-softmmu/hw/dma/omap_dma.o
  CC    aarch64-softmmu/hw/dma/soc_dma.o
  CC    aarch64-softmmu/hw/dma/pxa2xx_dma.o
  CC    aarch64-softmmu/hw/dma/bcm2835_dma.o
  CC    aarch64-softmmu/hw/gpio/omap_gpio.o
  CC    aarch64-softmmu/hw/gpio/imx_gpio.o
  CC    aarch64-softmmu/hw/i2c/omap_i2c.o
  CC    aarch64-softmmu/hw/input/pxa2xx_keypad.o
  CC    aarch64-softmmu/hw/input/tsc210x.o
  CC    aarch64-softmmu/hw/intc/armv7m_nvic.o
  CC    aarch64-softmmu/hw/intc/exynos4210_gic.o
  CC    aarch64-softmmu/hw/intc/exynos4210_combiner.o
  CC    aarch64-softmmu/hw/intc/omap_intc.o
  CC    aarch64-softmmu/hw/intc/bcm2835_ic.o
  CC    aarch64-softmmu/hw/intc/bcm2836_control.o
  CC    aarch64-softmmu/hw/intc/allwinner-a10-pic.o
  CC    aarch64-softmmu/hw/intc/aspeed_vic.o
  CC    aarch64-softmmu/hw/intc/arm_gicv3_cpuif.o
  CC    aarch64-softmmu/hw/misc/ivshmem.o
  CC    aarch64-softmmu/hw/misc/arm_sysctl.o
  CC    aarch64-softmmu/hw/misc/cbus.o
  CC    aarch64-softmmu/hw/misc/exynos4210_pmu.o
  CC    aarch64-softmmu/hw/misc/imx_ccm.o
  CC    aarch64-softmmu/hw/misc/imx31_ccm.o
  CC    aarch64-softmmu/hw/misc/imx25_ccm.o
  CC    aarch64-softmmu/hw/misc/imx6_ccm.o
  CC    aarch64-softmmu/hw/misc/imx6_src.o
  CC    aarch64-softmmu/hw/misc/mst_fpga.o
  CC    aarch64-softmmu/hw/misc/omap_clk.o
  CC    aarch64-softmmu/hw/misc/omap_gpmc.o
  CC    aarch64-softmmu/hw/misc/omap_l4.o
  CC    aarch64-softmmu/hw/misc/omap_sdrc.o
  CC    aarch64-softmmu/hw/misc/omap_tap.o
/tmp/qemu-test/src/hw/block/virtio-blk.c:471: error: conflicting types for ‘virtio_blk_handle_request’
/tmp/qemu-test/src/include/hw/virtio/virtio-blk.h:87: note: previous declaration of ‘virtio_blk_handle_request’ was here
/tmp/qemu-test/src/hw/block/virtio-blk.c: In function ‘virtio_blk_handle_request’:
/tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: implicit declaration of function ‘virtio_error’
/tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: nested extern declaration of ‘virtio_error’
  CC    aarch64-softmmu/hw/misc/bcm2835_mbox.o
make[1]: *** [hw/block/virtio-blk.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [subdir-aarch64-softmmu] Error 2
make: *** Waiting for unfinished jobs....
/tmp/qemu-test/src/hw/net/virtio-net.c: In function ‘virtio_net_handle_ctrl’:
/tmp/qemu-test/src/hw/net/virtio-net.c:895: warning: implicit declaration of function ‘virtio_error’
/tmp/qemu-test/src/hw/net/virtio-net.c:895: warning: nested extern declaration of ‘virtio_error’
make: *** [subdir-x86_64-softmmu] Error 2
tests/docker/Makefile.include:107: recipe for target 'docker-run-test-quick@centos6' failed
make: *** [docker-run-test-quick@centos6] Error 1
=== OUTPUT END ===

Test command exited with code: 2

---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 13:35 ` [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination no-reply
@ 2016-09-21 13:44   ` Greg Kurz
  2016-09-21 14:01     ` Fam Zheng
  2016-09-21 17:35     ` Michael S. Tsirkin
  0 siblings, 2 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 13:44 UTC (permalink / raw)
  To: no-reply
  Cc: famz, qemu-devel, kwolf, mst, jasowang, mreitz, aneesh.kumar,
	stefanha, cornelia.huck, pbonzini

On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
no-reply@patchew.org wrote:

> Hi,
> 
> Your series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce it
> locally.
> 

Heh... of course patchew doesn't know about Stefan's series. :)

Is there an appropriate way to avoid complaints when sending a patchset that
isn't based on QEMU master ?

> Type: series
> Message-id: 147446363181.4880.18104448248886932114.stgit@bahia
> Subject: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> set -e
> git submodule update --init dtc
> make J=8 docker-test-quick@centos6
> make J=8 docker-test-mingw@fedora
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> Switched to a new branch 'test'
> 4a3a53c virtio-scsi: handle virtio_scsi_set_config() error
> 7adf176 virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> 91e13db virtio-net: handle virtio_net_flush_tx() errors
> 540249a virtio-net: handle virtio_net_receive() errors
> 6a9bfcf virtio-net: handle virtio_net_handle_ctrl() error
> 65c4f5e virtio-blk: handle virtio_blk_handle_request() errors
> 538cc03 virtio-9p: handle handle_9p_output() error
> 
> === OUTPUT BEGIN ===
> Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
> Cloning into 'dtc'...
> Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
>   BUILD centos6
>   ARCHIVE qemu.tgz
>   ARCHIVE dtc.tgz
>   COPY RUNNER
>   RUN test-quick in centos6
> No C++ compiler available; disabling C++ specific optional code
> Install prefix    /tmp/qemu-test/src/tests/docker/install
> BIOS directory    /tmp/qemu-test/src/tests/docker/install/share/qemu
> binary directory  /tmp/qemu-test/src/tests/docker/install/bin
> library directory /tmp/qemu-test/src/tests/docker/install/lib
> module directory  /tmp/qemu-test/src/tests/docker/install/lib/qemu
> libexec directory /tmp/qemu-test/src/tests/docker/install/libexec
> include directory /tmp/qemu-test/src/tests/docker/install/include
> config directory  /tmp/qemu-test/src/tests/docker/install/etc
> local state directory   /tmp/qemu-test/src/tests/docker/install/var
> Manual directory  /tmp/qemu-test/src/tests/docker/install/share/man
> ELF interp prefix /usr/gnemul/qemu-%M
> Source path       /tmp/qemu-test/src
> C compiler        cc
> Host C compiler   cc
> C++ compiler      
> Objective-C compiler cc
> ARFLAGS           rv
> CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -g 
> QEMU_CFLAGS       -I/usr/include/pixman-1    -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all
> LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
> make              make
> install           install
> python            python -B
> smbd              /usr/sbin/smbd
> module support    no
> host CPU          x86_64
> host big endian   no
> target list       x86_64-softmmu aarch64-softmmu
> tcg debug enabled no
> gprof enabled     no
> sparse enabled    no
> strip binaries    yes
> profiler          no
> static build      no
> pixman            system
> SDL support       yes (1.2.14)
> GTK support       no 
> GTK GL support    no
> VTE support       no 
> TLS priority      NORMAL
> GNUTLS support    no
> GNUTLS rnd        no
> libgcrypt         no
> libgcrypt kdf     no
> nettle            no 
> nettle kdf        no
> libtasn1          no
> curses support    no
> virgl support     no
> curl support      no
> mingw32 support   no
> Audio drivers     oss
> Block whitelist (rw) 
> Block whitelist (ro) 
> VirtFS support    no
> VNC support       yes
> VNC SASL support  no
> VNC JPEG support  no
> VNC PNG support   no
> xen support       no
> brlapi support    no
> bluez  support    no
> Documentation     no
> PIE               yes
> vde support       no
> netmap support    no
> Linux AIO support no
> ATTR/XATTR support yes
> Install blobs     yes
> KVM support       yes
> RDMA support      no
> TCG interpreter   no
> fdt support       yes
> preadv support    yes
> fdatasync         yes
> madvise           yes
> posix_madvise     yes
> uuid support      no
> libcap-ng support no
> vhost-net support yes
> vhost-scsi support yes
> vhost-vsock support yes
> Trace backends    log
> spice support     no 
> rbd support       no
> xfsctl support    no
> smartcard support no
> libusb            no
> usb net redir     no
> OpenGL support    no
> OpenGL dmabufs    no
> libiscsi support  no
> libnfs support    no
> build guest agent yes
> QGA VSS support   no
> QGA w32 disk info no
> QGA MSI support   no
> seccomp support   no
> coroutine backend ucontext
> coroutine pool    yes
> GlusterFS support no
> Archipelago support no
> gcov              gcov
> gcov enabled      no
> TPM support       yes
> libssh2 support   no
> TPM passthrough   yes
> QOM debugging     yes
> vhdx              no
> lzo support       no
> snappy support    no
> bzip2 support     no
> NUMA host support no
> tcmalloc support  no
> jemalloc support  no
> avx2 optimization no
> replication support yes
>   GEN   x86_64-softmmu/config-devices.mak.tmp
>   GEN   aarch64-softmmu/config-devices.mak.tmp
>   GEN   config-host.h
>   GEN   qemu-options.def
>   GEN   qmp-commands.h
>   GEN   qapi-types.h
>   GEN   qapi-visit.h
>   GEN   qapi-event.h
>   GEN   x86_64-softmmu/config-devices.mak
>   GEN   aarch64-softmmu/config-devices.mak
>   GEN   qmp-introspect.h
>   GEN   tests/test-qapi-types.h
>   GEN   tests/test-qapi-visit.h
>   GEN   tests/test-qmp-commands.h
>   GEN   tests/test-qapi-event.h
>   GEN   tests/test-qmp-introspect.h
>   GEN   config-all-devices.mak
>   GEN   trace/generated-tracers.h
>   GEN   trace/generated-events.h
>   GEN   trace/generated-tcg-tracers.h
>   GEN   trace/generated-helpers-wrappers.h
>   GEN   trace/generated-helpers.h
>   CC    tests/qemu-iotests/socket_scm_helper.o
>   GEN   qga/qapi-generated/qga-qapi-types.h
>   GEN   qga/qapi-generated/qga-qapi-visit.h
>   GEN   qga/qapi-generated/qga-qmp-commands.h
>   GEN   qga/qapi-generated/qga-qapi-types.c
>   GEN   qga/qapi-generated/qga-qapi-visit.c
>   GEN   qga/qapi-generated/qga-qmp-marshal.c
>   GEN   qmp-introspect.c
>   GEN   qapi-types.c
>   GEN   qapi-visit.c
>   GEN   qapi-event.c
>   CC    qapi/qapi-visit-core.o
>   CC    qapi/qapi-dealloc-visitor.o
>   CC    qapi/qmp-input-visitor.o
>   CC    qapi/qmp-output-visitor.o
>   CC    qapi/qmp-registry.o
>   CC    qapi/qmp-dispatch.o
>   CC    qapi/string-input-visitor.o
>   CC    qapi/string-output-visitor.o
>   CC    qapi/opts-visitor.o
>   CC    qapi/qapi-clone-visitor.o
>   CC    qapi/qmp-event.o
>   CC    qapi/qapi-util.o
>   CC    qobject/qnull.o
>   CC    qobject/qint.o
>   CC    qobject/qstring.o
>   CC    qobject/qdict.o
>   CC    qobject/qlist.o
>   CC    qobject/qfloat.o
>   CC    qobject/qbool.o
>   CC    qobject/qjson.o
>   CC    qobject/qobject.o
>   CC    qobject/json-lexer.o
>   CC    qobject/json-streamer.o
>   CC    qobject/json-parser.o
>   GEN   trace/generated-events.c
>   CC    trace/control.o
>   CC    trace/qmp.o
>   CC    util/osdep.o
>   CC    util/cutils.o
>   CC    util/unicode.o
>   CC    util/qemu-timer-common.o
>   CC    util/bufferiszero.o
>   CC    util/compatfd.o
>   CC    util/event_notifier-posix.o
>   CC    util/mmap-alloc.o
>   CC    util/oslib-posix.o
>   CC    util/qemu-openpty.o
>   CC    util/qemu-thread-posix.o
>   CC    util/memfd.o
>   CC    util/envlist.o
>   CC    util/path.o
>   CC    util/module.o
>   CC    util/bitmap.o
>   CC    util/bitops.o
>   CC    util/hbitmap.o
>   CC    util/acl.o
>   CC    util/fifo8.o
>   CC    util/error.o
>   CC    util/qemu-error.o
>   CC    util/id.o
>   CC    util/iov.o
>   CC    util/qemu-config.o
>   CC    util/uri.o
>   CC    util/qemu-sockets.o
>   CC    util/notify.o
>   CC    util/qemu-option.o
>   CC    util/qemu-progress.o
>   CC    util/hexdump.o
>   CC    util/crc32c.o
>   CC    util/throttle.o
>   CC    util/getauxval.o
>   CC    util/readline.o
>   CC    util/rfifolock.o
>   CC    util/rcu.o
>   CC    util/qemu-coroutine.o
>   CC    util/qemu-coroutine-lock.o
>   CC    util/qemu-coroutine-io.o
>   CC    util/qemu-coroutine-sleep.o
>   CC    util/coroutine-ucontext.o
>   CC    util/timed-average.o
>   CC    util/buffer.o
>   CC    util/base64.o
>   CC    util/log.o
>   CC    util/qdist.o
>   CC    util/qht.o
> /tmp/qemu-test/src/util/qht.c: In function ‘qht_reset_size’:
> /tmp/qemu-test/src/util/qht.c:413: warning: ‘new’ may be used uninitialized in this function
>   CC    util/range.o
>   CC    crypto/pbkdf-stub.o
>   CC    stubs/arch-query-cpu-def.o
>   CC    stubs/arch-query-cpu-model-expansion.o
>   CC    stubs/arch-query-cpu-model-comparison.o
>   CC    stubs/arch-query-cpu-model-baseline.o
>   CC    stubs/bdrv-next-monitor-owned.o
>   CC    stubs/blk-commit-all.o
>   CC    stubs/blockdev-close-all-bdrv-states.o
>   CC    stubs/clock-warp.o
>   CC    stubs/cpu-get-clock.o
>   CC    stubs/cpu-get-icount.o
>   CC    stubs/dump.o
>   CC    stubs/fdset-add-fd.o
>   CC    stubs/fdset-get-fd.o
>   CC    stubs/fdset-find-fd.o
>   CC    stubs/fdset-remove-fd.o
>   CC    stubs/gdbstub.o
>   CC    stubs/get-fd.o
>   CC    stubs/get-next-serial.o
>   CC    stubs/get-vm-name.o
>   CC    stubs/iothread-lock.o
>   CC    stubs/is-daemonized.o
>   CC    stubs/machine-init-done.o
>   CC    stubs/migr-blocker.o
>   CC    stubs/mon-is-qmp.o
>   CC    stubs/mon-printf.o
>   CC    stubs/monitor-init.o
>   CC    stubs/notify-event.o
>   CC    stubs/qtest.o
>   CC    stubs/replay.o
>   CC    stubs/reset.o
>   CC    stubs/replay-user.o
>   CC    stubs/runstate-check.o
>   CC    stubs/set-fd-handler.o
>   CC    stubs/slirp.o
>   CC    stubs/sysbus.o
>   CC    stubs/trace-control.o
>   CC    stubs/uuid.o
>   CC    stubs/vm-stop.o
>   CC    stubs/vmstate.o
>   CC    stubs/cpus.o
>   CC    stubs/kvm.o
>   CC    stubs/qmp_pc_dimm_device_list.o
>   CC    stubs/target-monitor-defs.o
>   CC    stubs/target-get-monitor-def.o
>   CC    stubs/vhost.o
>   CC    stubs/iohandler.o
>   CC    stubs/smbios_type_38.o
>   CC    stubs/pc_madt_cpu_entry.o
>   CC    stubs/ipmi.o
>   CC    contrib/ivshmem-client/ivshmem-client.o
>   CC    contrib/ivshmem-client/main.o
>   CC    contrib/ivshmem-server/ivshmem-server.o
>   CC    contrib/ivshmem-server/main.o
>   CC    qemu-nbd.o
>   CC    async.o
>   CC    thread-pool.o
>   CC    block.o
>   CC    blockjob.o
>   CC    main-loop.o
>   CC    iohandler.o
>   CC    qemu-timer.o
>   CC    aio-posix.o
>   CC    qemu-io-cmds.o
>   CC    replication.o
>   CC    block/raw_bsd.o
>   CC    block/qcow.o
>   CC    block/vdi.o
>   CC    block/vmdk.o
>   CC    block/cloop.o
>   CC    block/bochs.o
>   CC    block/vpc.o
>   CC    block/vvfat.o
>   CC    block/qcow2.o
>   CC    block/qcow2-refcount.o
>   CC    block/qcow2-cluster.o
>   CC    block/qcow2-snapshot.o
>   CC    block/qcow2-cache.o
>   CC    block/qed.o
>   CC    block/qed-gencb.o
>   CC    block/qed-l2-cache.o
>   CC    block/qed-table.o
>   CC    block/qed-cluster.o
>   CC    block/qed-check.o
>   CC    block/quorum.o
>   CC    block/parallels.o
>   CC    block/blkdebug.o
>   CC    block/blkverify.o
>   CC    block/blkreplay.o
>   CC    block/block-backend.o
>   CC    block/snapshot.o
>   CC    block/qapi.o
>   CC    block/raw-posix.o
>   CC    block/null.o
>   CC    block/mirror.o
>   CC    block/commit.o
>   CC    block/io.o
>   CC    block/throttle-groups.o
>   CC    block/nbd.o
>   CC    block/nbd-client.o
>   CC    block/sheepdog.o
>   CC    block/accounting.o
>   CC    block/dirty-bitmap.o
>   CC    block/write-threshold.o
>   CC    block/backup.o
>   CC    block/replication.o
>   CC    block/crypto.o
>   CC    nbd/server.o
>   CC    nbd/client.o
>   CC    nbd/common.o
>   CC    block/dmg.o
>   CC    crypto/init.o
>   CC    crypto/hash.o
>   CC    crypto/hash-glib.o
>   CC    crypto/aes.o
>   CC    crypto/desrfb.o
>   CC    crypto/cipher.o
>   CC    crypto/tlscreds.o
>   CC    crypto/tlscredsanon.o
>   CC    crypto/tlscredsx509.o
>   CC    crypto/tlssession.o
>   CC    crypto/secret.o
>   CC    crypto/random-platform.o
>   CC    crypto/pbkdf.o
>   CC    crypto/ivgen.o
>   CC    crypto/ivgen-essiv.o
>   CC    crypto/ivgen-plain.o
>   CC    crypto/ivgen-plain64.o
>   CC    crypto/afsplit.o
>   CC    crypto/xts.o
>   CC    crypto/block.o
>   CC    crypto/block-qcow.o
>   CC    crypto/block-luks.o
>   CC    io/channel.o
>   CC    io/channel-buffer.o
>   CC    io/channel-command.o
>   CC    io/channel-file.o
>   CC    io/channel-socket.o
>   CC    io/channel-tls.o
>   CC    io/channel-watch.o
>   CC    io/channel-websock.o
>   CC    io/channel-util.o
>   CC    io/task.o
>   CC    qom/object.o
>   CC    qom/container.o
>   CC    qom/qom-qobject.o
>   CC    qom/object_interfaces.o
>   GEN   qemu-img-cmds.h
>   CC    qemu-io.o
>   CC    qemu-bridge-helper.o
>   CC    blockdev.o
>   CC    blockdev-nbd.o
>   CC    iothread.o
>   CC    qdev-monitor.o
>   CC    device-hotplug.o
>   CC    os-posix.o
>   CC    qemu-char.o
>   CC    page_cache.o
>   CC    accel.o
>   CC    bt-host.o
>   CC    bt-vhci.o
>   CC    dma-helpers.o
>   CC    vl.o
>   CC    tpm.o
>   CC    device_tree.o
>   GEN   qmp-marshal.c
>   CC    qmp.o
>   CC    hmp.o
>   CC    tcg-runtime.o
>   CC    audio/audio.o
>   CC    audio/noaudio.o
>   CC    audio/wavaudio.o
>   CC    audio/mixeng.o
>   CC    audio/sdlaudio.o
>   CC    audio/ossaudio.o
>   CC    audio/wavcapture.o
>   CC    backends/rng.o
>   CC    backends/rng-egd.o
>   CC    backends/rng-random.o
>   CC    backends/msmouse.o
>   CC    backends/testdev.o
>   CC    backends/tpm.o
>   CC    backends/hostmem.o
>   CC    backends/hostmem-ram.o
>   CC    backends/hostmem-file.o
>   CC    block/stream.o
>   CC    disas/arm.o
>   CC    disas/i386.o
>   CC    fsdev/qemu-fsdev-dummy.o
>   CC    hw/acpi/core.o
>   CC    fsdev/qemu-fsdev-opts.o
>   CC    hw/acpi/piix4.o
>   CC    hw/acpi/pcihp.o
>   CC    hw/acpi/ich9.o
>   CC    hw/acpi/tco.o
>   CC    hw/acpi/cpu_hotplug.o
>   CC    hw/acpi/memory_hotplug.o
>   CC    hw/acpi/memory_hotplug_acpi_table.o
>   CC    hw/acpi/cpu.o
>   CC    hw/acpi/acpi_interface.o
>   CC    hw/acpi/bios-linker-loader.o
>   CC    hw/acpi/aml-build.o
>   CC    hw/acpi/ipmi.o
>   CC    hw/audio/sb16.o
>   CC    hw/audio/es1370.o
>   CC    hw/audio/ac97.o
>   CC    hw/audio/fmopl.o
>   CC    hw/audio/adlib.o
>   CC    hw/audio/gus.o
>   CC    hw/audio/gusemu_hal.o
>   CC    hw/audio/gusemu_mixer.o
>   CC    hw/audio/cs4231a.o
>   CC    hw/audio/intel-hda.o
>   CC    hw/audio/hda-codec.o
>   CC    hw/audio/pcspk.o
>   CC    hw/audio/wm8750.o
>   CC    hw/audio/pl041.o
>   CC    hw/audio/lm4549.o
>   CC    hw/audio/marvell_88w8618.o
>   CC    hw/block/block.o
>   CC    hw/block/cdrom.o
>   CC    hw/block/hd-geometry.o
>   CC    hw/block/fdc.o
>   CC    hw/block/m25p80.o
>   CC    hw/block/nand.o
>   CC    hw/block/pflash_cfi01.o
>   CC    hw/block/pflash_cfi02.o
>   CC    hw/block/onenand.o
>   CC    hw/block/ecc.o
>   CC    hw/block/nvme.o
>   CC    hw/bt/core.o
>   CC    hw/bt/l2cap.o
>   CC    hw/bt/sdp.o
>   CC    hw/bt/hci.o
>   CC    hw/bt/hid.o
>   CC    hw/bt/hci-csr.o
>   CC    hw/char/ipoctal232.o
>   CC    hw/char/parallel.o
>   CC    hw/char/pl011.o
>   CC    hw/char/serial.o
>   CC    hw/char/serial-isa.o
>   CC    hw/char/serial-pci.o
>   CC    hw/char/virtio-console.o
>   CC    hw/char/cadence_uart.o
>   CC    hw/char/debugcon.o
>   CC    hw/char/imx_serial.o
>   CC    hw/core/qdev.o
>   CC    hw/core/qdev-properties.o
>   CC    hw/core/bus.o
>   CC    hw/core/fw-path-provider.o
>   CC    hw/core/irq.o
>   CC    hw/core/hotplug.o
>   CC    hw/core/ptimer.o
>   CC    hw/core/sysbus.o
>   CC    hw/core/machine.o
>   CC    hw/core/null-machine.o
>   CC    hw/core/loader.o
>   CC    hw/core/qdev-properties-system.o
>   CC    hw/core/register.o
>   CC    hw/core/platform-bus.o
>   CC    hw/display/ads7846.o
>   CC    hw/display/cirrus_vga.o
>   CC    hw/display/pl110.o
>   CC    hw/display/ssd0303.o
>   CC    hw/display/vga-pci.o
>   CC    hw/display/ssd0323.o
>   CC    hw/display/vga-isa.o
>   CC    hw/display/vmware_vga.o
>   CC    hw/display/blizzard.o
>   CC    hw/display/exynos4210_fimd.o
>   CC    hw/display/framebuffer.o
>   CC    hw/display/tc6393xb.o
>   CC    hw/dma/pl080.o
>   CC    hw/dma/pl330.o
>   CC    hw/dma/i8257.o
>   CC    hw/dma/xlnx-zynq-devcfg.o
>   CC    hw/gpio/max7310.o
>   CC    hw/gpio/pl061.o
>   CC    hw/gpio/zaurus.o
>   CC    hw/gpio/gpio_key.o
>   CC    hw/i2c/core.o
>   CC    hw/i2c/smbus.o
>   CC    hw/i2c/smbus_eeprom.o
>   CC    hw/i2c/i2c-ddc.o
>   CC    hw/i2c/versatile_i2c.o
>   CC    hw/i2c/smbus_ich9.o
>   CC    hw/i2c/pm_smbus.o
>   CC    hw/i2c/bitbang_i2c.o
>   CC    hw/i2c/exynos4210_i2c.o
>   CC    hw/i2c/imx_i2c.o
>   CC    hw/i2c/aspeed_i2c.o
>   CC    hw/ide/core.o
>   CC    hw/ide/atapi.o
>   CC    hw/ide/qdev.o
>   CC    hw/ide/pci.o
>   CC    hw/ide/isa.o
>   CC    hw/ide/piix.o
>   CC    hw/ide/microdrive.o
>   CC    hw/ide/ahci.o
>   CC    hw/ide/ich.o
>   CC    hw/input/hid.o
>   CC    hw/input/lm832x.o
>   CC    hw/input/pckbd.o
>   CC    hw/input/pl050.o
>   CC    hw/input/ps2.o
>   CC    hw/input/stellaris_input.o
>   CC    hw/input/tsc2005.o
>   CC    hw/input/vmmouse.o
>   CC    hw/input/virtio-input.o
>   CC    hw/input/virtio-input-hid.o
>   CC    hw/input/virtio-input-host.o
>   CC    hw/intc/i8259_common.o
>   CC    hw/intc/i8259.o
>   CC    hw/intc/pl190.o
>   CC    hw/intc/imx_avic.o
>   CC    hw/intc/realview_gic.o
>   CC    hw/intc/ioapic_common.o
>   CC    hw/intc/arm_gic_common.o
>   CC    hw/intc/arm_gic.o
>   CC    hw/intc/arm_gicv2m.o
>   CC    hw/intc/arm_gicv3_common.o
>   CC    hw/intc/arm_gicv3.o
>   CC    hw/intc/arm_gicv3_dist.o
>   CC    hw/intc/arm_gicv3_redist.o
>   CC    hw/ipack/ipack.o
>   CC    hw/ipack/tpci200.o
>   CC    hw/ipmi/ipmi.o
>   CC    hw/ipmi/ipmi_bmc_sim.o
>   CC    hw/ipmi/ipmi_bmc_extern.o
>   CC    hw/ipmi/isa_ipmi_kcs.o
>   CC    hw/ipmi/isa_ipmi_bt.o
>   CC    hw/isa/isa-bus.o
>   CC    hw/isa/apm.o
>   CC    hw/mem/pc-dimm.o
>   CC    hw/mem/nvdimm.o
>   CC    hw/misc/applesmc.o
>   CC    hw/misc/max111x.o
>   CC    hw/misc/tmp105.o
>   CC    hw/misc/debugexit.o
>   CC    hw/misc/sga.o
>   CC    hw/misc/pc-testdev.o
>   CC    hw/misc/pci-testdev.o
>   CC    hw/misc/arm_l2x0.o
>   CC    hw/misc/arm_integrator_debug.o
>   CC    hw/misc/a9scu.o
>   CC    hw/misc/arm11scu.o
>   CC    hw/net/ne2000.o
>   CC    hw/net/eepro100.o
>   CC    hw/net/pcnet-pci.o
>   CC    hw/net/pcnet.o
>   CC    hw/net/e1000.o
>   CC    hw/net/e1000x_common.o
>   CC    hw/net/net_tx_pkt.o
>   CC    hw/net/net_rx_pkt.o
>   CC    hw/net/e1000e.o
>   CC    hw/net/e1000e_core.o
>   CC    hw/net/rtl8139.o
>   CC    hw/net/vmxnet3.o
>   CC    hw/net/smc91c111.o
>   CC    hw/net/lan9118.o
>   CC    hw/net/ne2000-isa.o
>   CC    hw/net/xgmac.o
>   CC    hw/net/allwinner_emac.o
>   CC    hw/net/imx_fec.o
>   CC    hw/net/cadence_gem.o
>   CC    hw/net/stellaris_enet.o
>   CC    hw/net/rocker/rocker.o
>   CC    hw/net/rocker/rocker_fp.o
>   CC    hw/net/rocker/rocker_desc.o
>   CC    hw/net/rocker/rocker_world.o
>   CC    hw/net/rocker/rocker_of_dpa.o
>   CC    hw/nvram/eeprom93xx.o
>   CC    hw/nvram/fw_cfg.o
>   CC    hw/pci-bridge/pci_bridge_dev.o
>   CC    hw/pci-bridge/pci_expander_bridge.o
>   CC    hw/pci-bridge/xio3130_upstream.o
>   CC    hw/pci-bridge/xio3130_downstream.o
>   CC    hw/pci-bridge/ioh3420.o
>   CC    hw/pci-bridge/i82801b11.o
>   CC    hw/pci-host/pam.o
>   CC    hw/pci-host/versatile.o
>   CC    hw/pci-host/piix.o
>   CC    hw/pci-host/q35.o
>   CC    hw/pci-host/gpex.o
>   CC    hw/pci/pci.o
>   CC    hw/pci/pci_bridge.o
>   CC    hw/pci/msix.o
>   CC    hw/pci/msi.o
>   CC    hw/pci/shpc.o
>   CC    hw/pci/slotid_cap.o
>   CC    hw/pci/pci_host.o
>   CC    hw/pci/pcie_host.o
>   CC    hw/pci/pcie.o
>   CC    hw/pci/pcie_aer.o
>   CC    hw/pci/pcie_port.o
>   CC    hw/pci/pci-stub.o
>   CC    hw/pcmcia/pcmcia.o
>   CC    hw/scsi/scsi-disk.o
>   CC    hw/scsi/scsi-generic.o
>   CC    hw/scsi/scsi-bus.o
>   CC    hw/scsi/lsi53c895a.o
>   CC    hw/scsi/mptsas.o
> /tmp/qemu-test/src/hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’:
> /tmp/qemu-test/src/hw/nvram/fw_cfg.c:330: warning: ‘read’ may be used uninitialized in this function
>   CC    hw/scsi/mptconfig.o
>   CC    hw/scsi/mptendian.o
>   CC    hw/scsi/megasas.o
>   CC    hw/scsi/vmw_pvscsi.o
>   CC    hw/scsi/esp.o
>   CC    hw/scsi/esp-pci.o
>   CC    hw/sd/pl181.o
>   CC    hw/sd/ssi-sd.o
>   CC    hw/sd/sd.o
>   CC    hw/sd/core.o
>   CC    hw/sd/sdhci.o
>   CC    hw/smbios/smbios.o
>   CC    hw/smbios/smbios_type_38.o
>   CC    hw/ssi/pl022.o
>   CC    hw/ssi/ssi.o
>   CC    hw/ssi/xilinx_spips.o
>   CC    hw/ssi/aspeed_smc.o
>   CC    hw/timer/arm_timer.o
>   CC    hw/timer/arm_mptimer.o
>   CC    hw/timer/a9gtimer.o
>   CC    hw/timer/cadence_ttc.o
>   CC    hw/timer/ds1338.o
>   CC    hw/timer/hpet.o
>   CC    hw/timer/i8254_common.o
>   CC    hw/timer/i8254.o
>   CC    hw/timer/pl031.o
>   CC    hw/timer/twl92230.o
>   CC    hw/timer/imx_epit.o
>   CC    hw/timer/imx_gpt.o
>   CC    hw/timer/stm32f2xx_timer.o
>   CC    hw/timer/aspeed_timer.o
>   CC    hw/tpm/tpm_tis.o
>   CC    hw/tpm/tpm_passthrough.o
>   CC    hw/tpm/tpm_util.o
>   CC    hw/usb/core.o
>   CC    hw/usb/combined-packet.o
>   CC    hw/usb/bus.o
>   CC    hw/usb/libhw.o
>   CC    hw/usb/desc.o
>   CC    hw/usb/desc-msos.o
>   CC    hw/usb/hcd-uhci.o
>   CC    hw/usb/hcd-ohci.o
>   CC    hw/usb/hcd-ehci.o
>   CC    hw/usb/hcd-ehci-pci.o
>   CC    hw/usb/hcd-ehci-sysbus.o
>   CC    hw/usb/hcd-xhci.o
>   CC    hw/usb/hcd-musb.o
>   CC    hw/usb/dev-hub.o
>   CC    hw/usb/dev-hid.o
>   CC    hw/usb/dev-wacom.o
>   CC    hw/usb/dev-storage.o
>   CC    hw/usb/dev-uas.o
>   CC    hw/usb/dev-audio.o
>   CC    hw/usb/dev-serial.o
>   CC    hw/usb/dev-network.o
>   CC    hw/usb/dev-bluetooth.o
>   CC    hw/usb/dev-smartcard-reader.o
>   CC    hw/usb/dev-mtp.o
>   CC    hw/usb/host-stub.o
>   CC    hw/virtio/virtio-rng.o
>   CC    hw/virtio/virtio-pci.o
>   CC    hw/virtio/virtio-bus.o
>   CC    hw/virtio/virtio-mmio.o
>   CC    hw/watchdog/watchdog.o
>   CC    hw/watchdog/wdt_i6300esb.o
>   CC    hw/watchdog/wdt_ib700.o
>   CC    migration/migration.o
>   CC    migration/socket.o
>   CC    migration/fd.o
>   CC    migration/exec.o
>   CC    migration/tls.o
>   CC    migration/vmstate.o
>   CC    migration/qemu-file.o
>   CC    migration/qemu-file-channel.o
>   CC    migration/xbzrle.o
>   CC    migration/postcopy-ram.o
>   CC    migration/qjson.o
>   CC    migration/block.o
>   CC    net/net.o
>   CC    net/queue.o
>   CC    net/checksum.o
>   CC    net/util.o
>   CC    net/hub.o
>   CC    net/socket.o
>   CC    net/dump.o
>   CC    net/eth.o
>   CC    net/l2tpv3.o
>   CC    net/tap.o
>   CC    net/vhost-user.o
>   CC    net/tap-linux.o
>   CC    net/slirp.o
>   CC    net/filter.o
>   CC    net/filter-buffer.o
>   CC    net/filter-mirror.o
>   CC    qom/cpu.o
>   CC    replay/replay.o
>   CC    replay/replay-internal.o
>   CC    replay/replay-events.o
>   CC    replay/replay-time.o
>   CC    replay/replay-input.o
>   CC    replay/replay-char.o
>   CC    slirp/cksum.o
>   CC    slirp/if.o
>   CC    slirp/ip6_icmp.o
>   CC    slirp/ip_icmp.o
>   CC    slirp/ip6_input.o
>   CC    slirp/ip6_output.o
>   CC    slirp/ip_input.o
>   CC    slirp/ip_output.o
>   CC    slirp/dnssearch.o
>   CC    slirp/dhcpv6.o
>   CC    slirp/slirp.o
>   CC    slirp/mbuf.o
>   CC    slirp/misc.o
>   CC    slirp/sbuf.o
>   CC    slirp/socket.o
>   CC    slirp/tcp_input.o
>   CC    slirp/tcp_output.o
>   CC    slirp/tcp_subr.o
>   CC    slirp/tcp_timer.o
>   CC    slirp/udp.o
>   CC    slirp/udp6.o
>   CC    slirp/bootp.o
> /tmp/qemu-test/src/slirp/tcp_input.c: In function ‘tcp_input’:
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_p’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_len’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_tos’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_id’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_off’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_ttl’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_sum’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_src.s_addr’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_dst.s_addr’ may be used uninitialized in this function
> /tmp/qemu-test/src/slirp/tcp_input.c:220: warning: ‘save_ip6.ip_nh’ may be used uninitialized in this function
>   CC    slirp/tftp.o
>   CC    slirp/arp_table.o
>   CC    slirp/ndp_table.o
>   CC    ui/keymaps.o
>   CC    ui/console.o
>   CC    ui/cursor.o
>   CC    ui/qemu-pixman.o
>   CC    ui/input.o
>   CC    ui/input-keymap.o
>   CC    ui/input-legacy.o
>   CC    ui/input-linux.o
>   CC    ui/sdl.o
>   CC    ui/sdl_zoom.o
> /tmp/qemu-test/src/replay/replay-internal.c: In function ‘replay_put_array’:
> /tmp/qemu-test/src/replay/replay-internal.c:68: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
>   CC    ui/x_keymap.o
>   CC    ui/vnc.o
>   CC    ui/vnc-enc-zlib.o
>   CC    ui/vnc-enc-hextile.o
>   CC    ui/vnc-enc-tight.o
>   CC    ui/vnc-palette.o
>   CC    ui/vnc-enc-zrle.o
>   CC    ui/vnc-auth-vencrypt.o
>   CC    ui/vnc-ws.o
>   CC    ui/vnc-jobs.o
>   LINK  tests/qemu-iotests/socket_scm_helper
>   CC    qga/commands.o
>   CC    qga/guest-agent-command-state.o
>   CC    qga/main.o
>   CC    qga/commands-posix.o
>   CC    qga/channel-posix.o
>   CC    qga/qapi-generated/qga-qapi-types.o
>   CC    qga/qapi-generated/qga-qapi-visit.o
>   CC    qga/qapi-generated/qga-qmp-marshal.o
>   CC    qmp-introspect.o
>   CC    qapi-types.o
>   CC    qapi-visit.o
>   CC    qapi-event.o
>   AR    libqemustub.a
>   CC    qemu-img.o
>   CC    qmp-marshal.o
>   CC    trace/generated-events.o
>   AS    optionrom/multiboot.o
>   AS    optionrom/linuxboot.o
>   CC    optionrom/linuxboot_dma.o
>   AS    optionrom/kvmvapic.o
> cc: unrecognized option '-no-integrated-as'
> cc: unrecognized option '-no-integrated-as'
>   Building optionrom/multiboot.img
>   Building optionrom/linuxboot_dma.img
>   Building optionrom/linuxboot.img
>   Building optionrom/kvmvapic.img
>   Building optionrom/multiboot.raw
>   Building optionrom/linuxboot.raw
>   Building optionrom/linuxboot_dma.raw
>   AR    libqemuutil.a
>   Building optionrom/kvmvapic.raw
>   Signing optionrom/linuxboot.bin
>   Signing optionrom/multiboot.bin
>   Signing optionrom/linuxboot_dma.bin
>   Signing optionrom/kvmvapic.bin
>   LINK  qemu-ga
>   LINK  ivshmem-client
>   LINK  ivshmem-server
>   LINK  qemu-nbd
>   LINK  qemu-img
>   LINK  qemu-io
>   LINK  qemu-bridge-helper
>   GEN   x86_64-softmmu/hmp-commands.h
>   GEN   x86_64-softmmu/hmp-commands-info.h
>   GEN   x86_64-softmmu/config-target.h
>   CC    x86_64-softmmu/exec.o
>   CC    x86_64-softmmu/cpu-exec.o
>   CC    x86_64-softmmu/translate-all.o
>   CC    x86_64-softmmu/translate-common.o
>   CC    x86_64-softmmu/tcg/tcg-op.o
>   CC    x86_64-softmmu/cpu-exec-common.o
>   CC    x86_64-softmmu/tcg/tcg.o
>   GEN   aarch64-softmmu/hmp-commands.h
>   CC    x86_64-softmmu/tcg/optimize.o
>   CC    x86_64-softmmu/tcg/tcg-common.o
>   CC    x86_64-softmmu/fpu/softfloat.o
>   CC    x86_64-softmmu/disas.o
>   GEN   aarch64-softmmu/hmp-commands-info.h
>   CC    x86_64-softmmu/arch_init.o
>   CC    x86_64-softmmu/cpus.o
>   CC    x86_64-softmmu/monitor.o
>   GEN   aarch64-softmmu/config-target.h
>   CC    x86_64-softmmu/gdbstub.o
>   CC    aarch64-softmmu/exec.o
>   CC    x86_64-softmmu/balloon.o
>   CC    aarch64-softmmu/translate-all.o
>   CC    aarch64-softmmu/cpu-exec.o
>   CC    x86_64-softmmu/ioport.o
>   CC    aarch64-softmmu/translate-common.o
>   CC    x86_64-softmmu/numa.o
>   CC    aarch64-softmmu/cpu-exec-common.o
>   CC    x86_64-softmmu/qtest.o
>   CC    aarch64-softmmu/tcg/tcg.o
>   CC    x86_64-softmmu/bootdevice.o
>   CC    aarch64-softmmu/tcg/tcg-op.o
>   CC    x86_64-softmmu/kvm-all.o
>   CC    x86_64-softmmu/memory.o
>   CC    x86_64-softmmu/cputlb.o
>   CC    x86_64-softmmu/memory_mapping.o
>   CC    aarch64-softmmu/tcg/optimize.o
>   CC    x86_64-softmmu/dump.o
>   CC    aarch64-softmmu/tcg/tcg-common.o
>   CC    x86_64-softmmu/migration/ram.o
>   CC    aarch64-softmmu/fpu/softfloat.o
>   CC    aarch64-softmmu/disas.o
>   CC    x86_64-softmmu/migration/savevm.o
>   CC    x86_64-softmmu/xen-common-stub.o
>   CC    x86_64-softmmu/xen-hvm-stub.o
>   CC    x86_64-softmmu/hw/acpi/nvdimm.o
>   GEN   aarch64-softmmu/gdbstub-xml.c
>   CC    x86_64-softmmu/hw/block/virtio-blk.o
>   CC    x86_64-softmmu/hw/block/dataplane/virtio-blk.o
>   CC    x86_64-softmmu/hw/char/virtio-serial-bus.o
>   CC    x86_64-softmmu/hw/core/nmi.o
>   CC    x86_64-softmmu/hw/cpu/core.o
>   CC    x86_64-softmmu/hw/display/vga.o
>   CC    aarch64-softmmu/kvm-stub.o
>   CC    aarch64-softmmu/arch_init.o
>   CC    x86_64-softmmu/hw/display/virtio-gpu.o
>   CC    aarch64-softmmu/cpus.o
>   CC    x86_64-softmmu/hw/display/virtio-gpu-3d.o
>   CC    x86_64-softmmu/hw/display/virtio-gpu-pci.o
>   CC    aarch64-softmmu/monitor.o
>   CC    x86_64-softmmu/hw/display/virtio-vga.o
>   CC    x86_64-softmmu/hw/intc/apic.o
>   CC    x86_64-softmmu/hw/intc/apic_common.o
>   CC    aarch64-softmmu/gdbstub.o
>   CC    aarch64-softmmu/balloon.o
>   CC    x86_64-softmmu/hw/intc/ioapic.o
>   CC    aarch64-softmmu/ioport.o
>   CC    aarch64-softmmu/numa.o
>   CC    aarch64-softmmu/qtest.o
>   CC    aarch64-softmmu/bootdevice.o
>   CC    x86_64-softmmu/hw/isa/lpc_ich9.o
>   CC    aarch64-softmmu/memory.o
>   CC    aarch64-softmmu/cputlb.o
>   CC    x86_64-softmmu/hw/misc/vmport.o
>   CC    x86_64-softmmu/hw/misc/ivshmem.o
>   CC    x86_64-softmmu/hw/misc/pvpanic.o
>   CC    x86_64-softmmu/hw/misc/edu.o
>   CC    x86_64-softmmu/hw/misc/hyperv_testdev.o
>   CC    x86_64-softmmu/hw/net/virtio-net.o
>   CC    x86_64-softmmu/hw/net/vhost_net.o
>   CC    x86_64-softmmu/hw/scsi/virtio-scsi.o
>   CC    aarch64-softmmu/memory_mapping.o
>   CC    x86_64-softmmu/hw/scsi/virtio-scsi-dataplane.o
>   CC    x86_64-softmmu/hw/scsi/vhost-scsi.o
>   CC    aarch64-softmmu/dump.o
>   CC    aarch64-softmmu/migration/ram.o
>   CC    x86_64-softmmu/hw/timer/mc146818rtc.o
>   CC    x86_64-softmmu/hw/vfio/common.o
>   CC    aarch64-softmmu/migration/savevm.o
>   CC    aarch64-softmmu/xen-common-stub.o
>   CC    x86_64-softmmu/hw/vfio/pci.o
> /tmp/qemu-test/src/hw/block/virtio-blk.c:471: error: conflicting types for ‘virtio_blk_handle_request’
> /tmp/qemu-test/src/include/hw/virtio/virtio-blk.h:87: note: previous declaration of ‘virtio_blk_handle_request’ was here
> /tmp/qemu-test/src/hw/block/virtio-blk.c: In function ‘virtio_blk_handle_request’:
> /tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: implicit declaration of function ‘virtio_error’
> /tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: nested extern declaration of ‘virtio_error’
> make[1]: *** [hw/block/virtio-blk.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
>   CC    aarch64-softmmu/xen-hvm-stub.o
>   CC    aarch64-softmmu/hw/block/virtio-blk.o
>   CC    aarch64-softmmu/hw/block/dataplane/virtio-blk.o
>   CC    aarch64-softmmu/hw/char/exynos4210_uart.o
>   CC    aarch64-softmmu/hw/char/omap_uart.o
>   CC    aarch64-softmmu/hw/char/digic-uart.o
>   CC    aarch64-softmmu/hw/char/stm32f2xx_usart.o
>   CC    aarch64-softmmu/hw/char/bcm2835_aux.o
>   CC    aarch64-softmmu/hw/char/virtio-serial-bus.o
>   CC    aarch64-softmmu/hw/core/nmi.o
>   CC    aarch64-softmmu/hw/cpu/arm11mpcore.o
>   CC    aarch64-softmmu/hw/cpu/realview_mpcore.o
>   CC    aarch64-softmmu/hw/cpu/a9mpcore.o
>   CC    aarch64-softmmu/hw/cpu/a15mpcore.o
>   CC    aarch64-softmmu/hw/cpu/core.o
>   CC    aarch64-softmmu/hw/display/omap_dss.o
>   CC    aarch64-softmmu/hw/display/omap_lcdc.o
>   CC    aarch64-softmmu/hw/display/pxa2xx_lcd.o
>   CC    aarch64-softmmu/hw/display/bcm2835_fb.o
>   CC    aarch64-softmmu/hw/display/vga.o
>   CC    aarch64-softmmu/hw/display/virtio-gpu.o
>   CC    aarch64-softmmu/hw/display/virtio-gpu-3d.o
>   CC    aarch64-softmmu/hw/display/virtio-gpu-pci.o
> /tmp/qemu-test/src/hw/scsi/virtio-scsi.c: In function ‘virtio_scsi_bad_req’:
> /tmp/qemu-test/src/hw/scsi/virtio-scsi.c:86: warning: implicit declaration of function ‘virtio_error’
> /tmp/qemu-test/src/hw/scsi/virtio-scsi.c:86: warning: nested extern declaration of ‘virtio_error’
> /tmp/qemu-test/src/hw/scsi/virtio-scsi.c:86: error: ‘VirtIOSCSIReq’ has no member named ‘vdev’
> /tmp/qemu-test/src/hw/scsi/virtio-scsi.c: In function ‘virtio_scsi_handle_cmd_req_prepare’:
> /tmp/qemu-test/src/hw/scsi/virtio-scsi.c:537: error: too few arguments to function ‘virtio_scsi_bad_req’
> make[1]: *** [hw/scsi/virtio-scsi.o] Error 1
>   CC    aarch64-softmmu/hw/display/dpcd.o
>   CC    aarch64-softmmu/hw/display/xlnx_dp.o
>   CC    aarch64-softmmu/hw/dma/xlnx_dpdma.o
>   CC    aarch64-softmmu/hw/dma/omap_dma.o
>   CC    aarch64-softmmu/hw/dma/soc_dma.o
>   CC    aarch64-softmmu/hw/dma/pxa2xx_dma.o
>   CC    aarch64-softmmu/hw/dma/bcm2835_dma.o
>   CC    aarch64-softmmu/hw/gpio/omap_gpio.o
>   CC    aarch64-softmmu/hw/gpio/imx_gpio.o
>   CC    aarch64-softmmu/hw/i2c/omap_i2c.o
>   CC    aarch64-softmmu/hw/input/pxa2xx_keypad.o
>   CC    aarch64-softmmu/hw/input/tsc210x.o
>   CC    aarch64-softmmu/hw/intc/armv7m_nvic.o
>   CC    aarch64-softmmu/hw/intc/exynos4210_gic.o
>   CC    aarch64-softmmu/hw/intc/exynos4210_combiner.o
>   CC    aarch64-softmmu/hw/intc/omap_intc.o
>   CC    aarch64-softmmu/hw/intc/bcm2835_ic.o
>   CC    aarch64-softmmu/hw/intc/bcm2836_control.o
>   CC    aarch64-softmmu/hw/intc/allwinner-a10-pic.o
>   CC    aarch64-softmmu/hw/intc/aspeed_vic.o
>   CC    aarch64-softmmu/hw/intc/arm_gicv3_cpuif.o
>   CC    aarch64-softmmu/hw/misc/ivshmem.o
>   CC    aarch64-softmmu/hw/misc/arm_sysctl.o
>   CC    aarch64-softmmu/hw/misc/cbus.o
>   CC    aarch64-softmmu/hw/misc/exynos4210_pmu.o
>   CC    aarch64-softmmu/hw/misc/imx_ccm.o
>   CC    aarch64-softmmu/hw/misc/imx31_ccm.o
>   CC    aarch64-softmmu/hw/misc/imx25_ccm.o
>   CC    aarch64-softmmu/hw/misc/imx6_ccm.o
>   CC    aarch64-softmmu/hw/misc/imx6_src.o
>   CC    aarch64-softmmu/hw/misc/mst_fpga.o
>   CC    aarch64-softmmu/hw/misc/omap_clk.o
>   CC    aarch64-softmmu/hw/misc/omap_gpmc.o
>   CC    aarch64-softmmu/hw/misc/omap_l4.o
>   CC    aarch64-softmmu/hw/misc/omap_sdrc.o
>   CC    aarch64-softmmu/hw/misc/omap_tap.o
> /tmp/qemu-test/src/hw/block/virtio-blk.c:471: error: conflicting types for ‘virtio_blk_handle_request’
> /tmp/qemu-test/src/include/hw/virtio/virtio-blk.h:87: note: previous declaration of ‘virtio_blk_handle_request’ was here
> /tmp/qemu-test/src/hw/block/virtio-blk.c: In function ‘virtio_blk_handle_request’:
> /tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: implicit declaration of function ‘virtio_error’
> /tmp/qemu-test/src/hw/block/virtio-blk.c:482: warning: nested extern declaration of ‘virtio_error’
>   CC    aarch64-softmmu/hw/misc/bcm2835_mbox.o
> make[1]: *** [hw/block/virtio-blk.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [subdir-aarch64-softmmu] Error 2
> make: *** Waiting for unfinished jobs....
> /tmp/qemu-test/src/hw/net/virtio-net.c: In function ‘virtio_net_handle_ctrl’:
> /tmp/qemu-test/src/hw/net/virtio-net.c:895: warning: implicit declaration of function ‘virtio_error’
> /tmp/qemu-test/src/hw/net/virtio-net.c:895: warning: nested extern declaration of ‘virtio_error’
> make: *** [subdir-x86_64-softmmu] Error 2
> tests/docker/Makefile.include:107: recipe for target 'docker-run-test-quick@centos6' failed
> make: *** [docker-run-test-quick@centos6] Error 1
> === OUTPUT END ===
> 
> Test command exited with code: 2
> 
> 
> ---
> Email generated automatically by Patchew [http://patchew.org/].
> Please send your feedback to patchew-devel@freelists.org

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 13:44   ` Greg Kurz
@ 2016-09-21 14:01     ` Fam Zheng
  2016-09-21 14:29       ` Eric Blake
                         ` (2 more replies)
  2016-09-21 17:35     ` Michael S. Tsirkin
  1 sibling, 3 replies; 34+ messages in thread
From: Fam Zheng @ 2016-09-21 14:01 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, kwolf, mst, jasowang, mreitz, aneesh.kumar, stefanha,
	cornelia.huck, pbonzini

On Wed, 09/21 15:44, Greg Kurz wrote:
> On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
> no-reply@patchew.org wrote:
> 
> > Hi,
> > 
> > Your series failed automatic build test. Please find the testing commands and
> > their output below. If you have docker installed, you can probably reproduce it
> > locally.
> > 
> 
> Heh... of course patchew doesn't know about Stefan's series. :)

Usually those patchsets fail to apply and patchew keeps quiet. This series is
the first victim of a exception, seemingly. :)

> 
> Is there an appropriate way to avoid complaints when sending a patchset that
> isn't based on QEMU master ?

Currently we don't, but we can invent one. Like:

Base: http://github.com/someone/qemu branch

for the "base on maintainer tree" case, or just inform patchew to "pull"
instead of apply:

Git: http://github.com/someone/qemu topic

for the "base on the other series" case.

Supporting this is not complicated, the tricky thing is to remember to put that
magic in cover letters every time a series doesn't base on master.

Any thoughts on the harder question? :)

Fam

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error Greg Kurz
@ 2016-09-21 14:16   ` Cornelia Huck
  2016-09-21 14:38     ` Greg Kurz
  2016-09-21 14:42     ` Greg Kurz
  0 siblings, 2 replies; 34+ messages in thread
From: Cornelia Huck @ 2016-09-21 14:16 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 15:14:00 +0200
Greg Kurz <groug@kaod.org> wrote:

> A broken guest may send a request with only non-empty out buffers
> or only non-empty in buffers, virtqueue_pop() will then return a
> VirtQueueElement with out_num == 0 or in_num == 0 respectively.
> 
> All 9P requests are expected to start with the following 7-byte header:
> 
>             uint32_t size_le;
>             uint8_t id;
>             uint16_t tag_le;
> 
> If iov_to_buf() fails to return these 7 bytes, then something is wrong in
> the guest.
> 
> In both cases, it is wrong to crash QEMU, since the root cause lies in the
> guest. Let's switch the device to the broken state instead.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  hw/9pfs/virtio-9p-device.c |   14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> index 009b43f6d045..0f09bef13392 100644
> --- a/hw/9pfs/virtio-9p-device.c
> +++ b/hw/9pfs/virtio-9p-device.c
> @@ -56,13 +56,23 @@ static void handle_9p_output(VirtIODevice *vdev, VirtQueue *vq)
>              break;
>          }
> 
> -        BUG_ON(elem->out_num == 0 || elem->in_num == 0);
> +        if (elem->out_num == 0 || elem->in_num == 0) {
> +            virtio_error(vdev,
> +                         "The guest sent a VirtFS request without headers");
> +            pdu_free(pdu);
> +            return;

Make that 'break;' to be more consistent with the code right above?

> +        }
>          QEMU_BUILD_BUG_ON(sizeof out != 7);
> 
>          v->elems[pdu->idx] = elem;
>          len = iov_to_buf(elem->out_sg, elem->out_num, 0,
>                           &out, sizeof out);
> -        BUG_ON(len != sizeof out);
> +        if (len != sizeof out) {

I always find 'sizeof foo' instead of 'sizeof(foo)' a bit jarring...

> +            virtio_error(vdev, "The guest sent a malformed VirtFS request: "
> +                         "header size is %zd, should be 7", len);
> +            pdu_free(pdu);
> +            return;
> +        }
> 
>          pdu->size = le32_to_cpu(out.size_le);
> 
> 

Looks good to me.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors Greg Kurz
@ 2016-09-21 14:28   ` Cornelia Huck
  2016-09-21 15:01     ` Greg Kurz
  0 siblings, 1 reply; 34+ messages in thread
From: Cornelia Huck @ 2016-09-21 14:28 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 15:14:09 +0200
Greg Kurz <groug@kaod.org> wrote:

> All these errors are caused by a buggy guest: let's switch the device to
> the broken state instead of terminating QEMU.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  hw/block/virtio-blk.c |   27 +++++++++++++++++----------
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 3a6112fbf4c4..1285d196a40f 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -468,30 +468,32 @@ static bool virtio_blk_sect_range_ok(VirtIOBlock *dev,
>      return true;
>  }
> 
> -void virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
> +int virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)

Unrelated to your patch: It seems there are no callers (left) outside
of this file; should the function be made static?

Related to your patch: You didn't change the prototype in the header :)

(...)

> @@ -586,7 +589,9 @@ void virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
>      blk_io_plug(s->blk);
> 
>      while ((req = virtio_blk_get_request(s, vq))) {
> -        virtio_blk_handle_request(req, &mrb);
> +        if (virtio_blk_handle_request(req, &mrb)) {
> +            return;

Does the missing blk_io_unplug() have any side-effects outside of this
device, which is broken anyway?

> +        }
>      }
> 
>      if (mrb.num_reqs) {

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 14:01     ` Fam Zheng
@ 2016-09-21 14:29       ` Eric Blake
  2016-09-22  5:39         ` Fam Zheng
  2016-09-21 14:34       ` Greg Kurz
  2016-09-21 17:38       ` Michael S. Tsirkin
  2 siblings, 1 reply; 34+ messages in thread
From: Eric Blake @ 2016-09-21 14:29 UTC (permalink / raw)
  To: Fam Zheng, Greg Kurz
  Cc: kwolf, mst, jasowang, qemu-devel, mreitz, aneesh.kumar, stefanha,
	cornelia.huck, pbonzini

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

On 09/21/2016 09:01 AM, Fam Zheng wrote:
> On Wed, 09/21 15:44, Greg Kurz wrote:
>> On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
>> no-reply@patchew.org wrote:
>>
>>> Hi,
>>>
>>> Your series failed automatic build test. Please find the testing commands and
>>> their output below. If you have docker installed, you can probably reproduce it
>>> locally.
>>>
>>
>> Heh... of course patchew doesn't know about Stefan's series. :)
> 
> Usually those patchsets fail to apply and patchew keeps quiet. This series is
> the first victim of a exception, seemingly. :)

While we're at it, is there a way to make the error messages include the
last 15 lines or so of the build log first, and then the full build log?
 Usually, the failure is easy to identify from the tail of the message,
but having to scroll to the bottom past all the successful portion of
the log is slower than seeing the tail up front.  At the same time, the
full log is useful for the cases where the failure occurs earlier than
the last 15 lines.

> 
>>
>> Is there an appropriate way to avoid complaints when sending a patchset that
>> isn't based on QEMU master ?
> 
> Currently we don't, but we can invent one. Like:
> 
> Base: http://github.com/someone/qemu branch

I like that idea (these patches apply from that point; then it is up to
patchew whether to bother chasing down that point or just skipping the
series)

> 
> for the "base on maintainer tree" case, or just inform patchew to "pull"
> instead of apply:
> 
> Git: http://github.com/someone/qemu topic

Maybe Pull: instead of Git:, but again a nice idea.


> 
> for the "base on the other series" case.
> 
> Supporting this is not complicated, the tricky thing is to remember to put that
> magic in cover letters every time a series doesn't base on master.
> 
> Any thoughts on the harder question? :)

Which one was the harder question? How to get people to remember to use
magic that patchew can recognize?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error Greg Kurz
@ 2016-09-21 14:30   ` Cornelia Huck
  2016-09-21 15:03     ` Greg Kurz
  0 siblings, 1 reply; 34+ messages in thread
From: Cornelia Huck @ 2016-09-21 14:30 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 15:14:17 +0200
Greg Kurz <groug@kaod.org> wrote:

> This error is caused by a buggy guest: let's switch the device to the
> broken state instead of terminating QEMU.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  hw/net/virtio-net.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 01f1351554aa..68a448acd81b 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -892,8 +892,8 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>          }
>          if (iov_size(elem->in_sg, elem->in_num) < sizeof(status) ||
>              iov_size(elem->out_sg, elem->out_num) < sizeof(ctrl)) {
> -            error_report("virtio-net ctrl missing headers");
> -            exit(1);
> +            virtio_error(vdev, "virtio-net ctrl missing headers");
> +            return;

Do a 'break;' for consistency's sake?

>          }
> 
>          iov_cnt = elem->out_num;
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 14:01     ` Fam Zheng
  2016-09-21 14:29       ` Eric Blake
@ 2016-09-21 14:34       ` Greg Kurz
  2016-09-21 17:38       ` Michael S. Tsirkin
  2 siblings, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 14:34 UTC (permalink / raw)
  To: Fam Zheng
  Cc: qemu-devel, kwolf, mst, jasowang, mreitz, aneesh.kumar, stefanha,
	cornelia.huck, pbonzini

On Wed, 21 Sep 2016 22:01:30 +0800
Fam Zheng <famz@redhat.com> wrote:

> On Wed, 09/21 15:44, Greg Kurz wrote:
> > On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
> > no-reply@patchew.org wrote:
> >   
> > > Hi,
> > > 
> > > Your series failed automatic build test. Please find the testing commands and
> > > their output below. If you have docker installed, you can probably reproduce it
> > > locally.
> > >   
> > 
> > Heh... of course patchew doesn't know about Stefan's series. :)  
> 
> Usually those patchsets fail to apply and patchew keeps quiet. This series is
> the first victim of a exception, seemingly. :)
> 

This patchset applies indeed but calls a function that only exists in Stefan's
series. It is of course impossible for patchew to guess that :)

The default behaviour of keeping quiest when patchsets fail to apply is good
IMHO.

> > 
> > Is there an appropriate way to avoid complaints when sending a patchset that
> > isn't based on QEMU master ?  
> 
> Currently we don't, but we can invent one. Like:
> 
> Base: http://github.com/someone/qemu branch
> 
> for the "base on maintainer tree" case, or just inform patchew to "pull"
> instead of apply:
> 
> Git: http://github.com/someone/qemu topic
> 
> for the "base on the other series" case.
> 
> Supporting this is not complicated, the tricky thing is to remember to put that
> magic in cover letters every time a series doesn't base on master.
> 
> Any thoughts on the harder question? :)
> 

Be smart enough ? :)

> Fam

Cheers.

--
Greg

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 4/7] virtio-net: handle virtio_net_receive() errors
  2016-09-21 13:14 ` [Qemu-devel] [PATCH 4/7] virtio-net: handle virtio_net_receive() errors Greg Kurz
@ 2016-09-21 14:38   ` Cornelia Huck
  0 siblings, 0 replies; 34+ messages in thread
From: Cornelia Huck @ 2016-09-21 14:38 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 15:14:25 +0200
Greg Kurz <groug@kaod.org> wrote:

> All these errors are caused by a buggy guest: let's switch the device to
> the broken state instead of terminating QEMU.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  hw/net/virtio-net.c |   25 +++++++++++++------------
>  1 file changed, 13 insertions(+), 12 deletions(-)

Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error
  2016-09-21 14:16   ` Cornelia Huck
@ 2016-09-21 14:38     ` Greg Kurz
  2016-09-21 14:43       ` Cornelia Huck
  2016-09-21 14:42     ` Greg Kurz
  1 sibling, 1 reply; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 14:38 UTC (permalink / raw)
  To: Cornelia Huck
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 16:16:59 +0200
Cornelia Huck <cornelia.huck@de.ibm.com> wrote:

> On Wed, 21 Sep 2016 15:14:00 +0200
> Greg Kurz <groug@kaod.org> wrote:
> 
> > A broken guest may send a request with only non-empty out buffers
> > or only non-empty in buffers, virtqueue_pop() will then return a
> > VirtQueueElement with out_num == 0 or in_num == 0 respectively.
> > 
> > All 9P requests are expected to start with the following 7-byte header:
> > 
> >             uint32_t size_le;
> >             uint8_t id;
> >             uint16_t tag_le;
> > 
> > If iov_to_buf() fails to return these 7 bytes, then something is wrong in
> > the guest.
> > 
> > In both cases, it is wrong to crash QEMU, since the root cause lies in the
> > guest. Let's switch the device to the broken state instead.
> > 
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> > index 009b43f6d045..0f09bef13392 100644
> > --- a/hw/9pfs/virtio-9p-device.c
> > +++ b/hw/9pfs/virtio-9p-device.c
> > @@ -56,13 +56,23 @@ static void handle_9p_output(VirtIODevice *vdev, VirtQueue *vq)
> >              break;
> >          }
> > 
> > -        BUG_ON(elem->out_num == 0 || elem->in_num == 0);
> > +        if (elem->out_num == 0 || elem->in_num == 0) {
> > +            virtio_error(vdev,
> > +                         "The guest sent a VirtFS request without headers");
> > +            pdu_free(pdu);
> > +            return;  
> 
> Make that 'break;' to be more consistent with the code right above?
> 

The code right above isn't an error path, unlike here. Maybe I should
even add an out_err: label to make it explicit.

> > +        }
> >          QEMU_BUILD_BUG_ON(sizeof out != 7);
> > 
> >          v->elems[pdu->idx] = elem;
> >          len = iov_to_buf(elem->out_sg, elem->out_num, 0,
> >                           &out, sizeof out);
> > -        BUG_ON(len != sizeof out);
> > +        if (len != sizeof out) {  
> 
> I always find 'sizeof foo' instead of 'sizeof(foo)' a bit jarring...
> 
> > +            virtio_error(vdev, "The guest sent a malformed VirtFS request: "
> > +                         "header size is %zd, should be 7", len);
> > +            pdu_free(pdu);
> > +            return;

And same here.

> > +        }
> > 
> >          pdu->size = le32_to_cpu(out.size_le);
> > 
> >   
> 
> Looks good to me.
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error
  2016-09-21 14:16   ` Cornelia Huck
  2016-09-21 14:38     ` Greg Kurz
@ 2016-09-21 14:42     ` Greg Kurz
  1 sibling, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 14:42 UTC (permalink / raw)
  To: Cornelia Huck
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 16:16:59 +0200
Cornelia Huck <cornelia.huck@de.ibm.com> wrote:

> On Wed, 21 Sep 2016 15:14:00 +0200
> Greg Kurz <groug@kaod.org> wrote:
> 
> > A broken guest may send a request with only non-empty out buffers
> > or only non-empty in buffers, virtqueue_pop() will then return a
> > VirtQueueElement with out_num == 0 or in_num == 0 respectively.
> > 
> > All 9P requests are expected to start with the following 7-byte header:
> > 
> >             uint32_t size_le;
> >             uint8_t id;
> >             uint16_t tag_le;
> > 
> > If iov_to_buf() fails to return these 7 bytes, then something is wrong in
> > the guest.
> > 
> > In both cases, it is wrong to crash QEMU, since the root cause lies in the
> > guest. Let's switch the device to the broken state instead.
> > 
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> > index 009b43f6d045..0f09bef13392 100644
> > --- a/hw/9pfs/virtio-9p-device.c
> > +++ b/hw/9pfs/virtio-9p-device.c
> > @@ -56,13 +56,23 @@ static void handle_9p_output(VirtIODevice *vdev, VirtQueue *vq)
> >              break;
> >          }
> > 
> > -        BUG_ON(elem->out_num == 0 || elem->in_num == 0);
> > +        if (elem->out_num == 0 || elem->in_num == 0) {
> > +            virtio_error(vdev,
> > +                         "The guest sent a VirtFS request without headers");
> > +            pdu_free(pdu);
> > +            return;  
> 
> Make that 'break;' to be more consistent with the code right above?
> 
> > +        }
> >          QEMU_BUILD_BUG_ON(sizeof out != 7);
> > 
> >          v->elems[pdu->idx] = elem;
> >          len = iov_to_buf(elem->out_sg, elem->out_num, 0,
> >                           &out, sizeof out);
> > -        BUG_ON(len != sizeof out);
> > +        if (len != sizeof out) {  
> 
> I always find 'sizeof foo' instead of 'sizeof(foo)' a bit jarring...
> 

Oops... hit the send button to quickly :)

I agree. I will fix this in a preparatory patch.

> > +            virtio_error(vdev, "The guest sent a malformed VirtFS request: "
> > +                         "header size is %zd, should be 7", len);
> > +            pdu_free(pdu);
> > +            return;
> > +        }
> > 
> >          pdu->size = le32_to_cpu(out.size_le);
> > 
> >   
> 
> Looks good to me.
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error
  2016-09-21 14:38     ` Greg Kurz
@ 2016-09-21 14:43       ` Cornelia Huck
  0 siblings, 0 replies; 34+ messages in thread
From: Cornelia Huck @ 2016-09-21 14:43 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 16:38:26 +0200
Greg Kurz <groug@kaod.org> wrote:

> On Wed, 21 Sep 2016 16:16:59 +0200
> Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> 
> > On Wed, 21 Sep 2016 15:14:00 +0200
> > Greg Kurz <groug@kaod.org> wrote:
> > 
> > > A broken guest may send a request with only non-empty out buffers
> > > or only non-empty in buffers, virtqueue_pop() will then return a
> > > VirtQueueElement with out_num == 0 or in_num == 0 respectively.
> > > 
> > > All 9P requests are expected to start with the following 7-byte header:
> > > 
> > >             uint32_t size_le;
> > >             uint8_t id;
> > >             uint16_t tag_le;
> > > 
> > > If iov_to_buf() fails to return these 7 bytes, then something is wrong in
> > > the guest.
> > > 
> > > In both cases, it is wrong to crash QEMU, since the root cause lies in the
> > > guest. Let's switch the device to the broken state instead.
> > > 
> > > Signed-off-by: Greg Kurz <groug@kaod.org>
> > > ---
> > >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++++--
> > >  1 file changed, 12 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> > > index 009b43f6d045..0f09bef13392 100644
> > > --- a/hw/9pfs/virtio-9p-device.c
> > > +++ b/hw/9pfs/virtio-9p-device.c
> > > @@ -56,13 +56,23 @@ static void handle_9p_output(VirtIODevice *vdev, VirtQueue *vq)
> > >              break;
> > >          }
> > > 
> > > -        BUG_ON(elem->out_num == 0 || elem->in_num == 0);
> > > +        if (elem->out_num == 0 || elem->in_num == 0) {
> > > +            virtio_error(vdev,
> > > +                         "The guest sent a VirtFS request without headers");
> > > +            pdu_free(pdu);
> > > +            return;  
> > 
> > Make that 'break;' to be more consistent with the code right above?
> > 
> 
> The code right above isn't an error path, unlike here. Maybe I should
> even add an out_err: label to make it explicit.

I think our tastes differ a bit. But it's your code :)

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors
  2016-09-21 14:28   ` Cornelia Huck
@ 2016-09-21 15:01     ` Greg Kurz
  0 siblings, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 15:01 UTC (permalink / raw)
  To: Cornelia Huck
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 16:28:34 +0200
Cornelia Huck <cornelia.huck@de.ibm.com> wrote:

> On Wed, 21 Sep 2016 15:14:09 +0200
> Greg Kurz <groug@kaod.org> wrote:
> 
> > All these errors are caused by a buggy guest: let's switch the device to
> > the broken state instead of terminating QEMU.
> > 
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  hw/block/virtio-blk.c |   27 +++++++++++++++++----------
> >  1 file changed, 17 insertions(+), 10 deletions(-)
> > 
> > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> > index 3a6112fbf4c4..1285d196a40f 100644
> > --- a/hw/block/virtio-blk.c
> > +++ b/hw/block/virtio-blk.c
> > @@ -468,30 +468,32 @@ static bool virtio_blk_sect_range_ok(VirtIOBlock *dev,
> >      return true;
> >  }
> > 
> > -void virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
> > +int virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)  
> 
> Unrelated to your patch: It seems there are no callers (left) outside
> of this file; should the function be made static?
> 

Yeah you're right. The dataplane does not call this function anymore since:

"03de2f527499 virtio-blk: do not use vring in dataplane"

I'll fix this in a preparatory patch.

> Related to your patch: You didn't change the prototype in the header :)
> 

Oops... caught in the act of not running a final build before sending :)

> (...)
> 
> > @@ -586,7 +589,9 @@ void virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
> >      blk_io_plug(s->blk);
> > 
> >      while ((req = virtio_blk_get_request(s, vq))) {
> > -        virtio_blk_handle_request(req, &mrb);
> > +        if (virtio_blk_handle_request(req, &mrb)) {
> > +            return;  
> 
> Does the missing blk_io_unplug() have any side-effects outside of this
> device, which is broken anyway?
> 

Ugh, this is not intentional... and since it may go down many paths, I
won't bet there are no side effects.

I'll fix this with an explicit err_out: label.

> > +        }
> >      }
> > 
> >      if (mrb.num_reqs) {  
> 
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error
  2016-09-21 14:30   ` Cornelia Huck
@ 2016-09-21 15:03     ` Greg Kurz
  0 siblings, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 15:03 UTC (permalink / raw)
  To: Cornelia Huck
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Wed, 21 Sep 2016 16:30:16 +0200
Cornelia Huck <cornelia.huck@de.ibm.com> wrote:

> On Wed, 21 Sep 2016 15:14:17 +0200
> Greg Kurz <groug@kaod.org> wrote:
> 
> > This error is caused by a buggy guest: let's switch the device to the
> > broken state instead of terminating QEMU.
> > 
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  hw/net/virtio-net.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 01f1351554aa..68a448acd81b 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -892,8 +892,8 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> >          }
> >          if (iov_size(elem->in_sg, elem->in_num) < sizeof(status) ||
> >              iov_size(elem->out_sg, elem->out_num) < sizeof(ctrl)) {
> > -            error_report("virtio-net ctrl missing headers");
> > -            exit(1);
> > +            virtio_error(vdev, "virtio-net ctrl missing headers");
> > +            return;  
> 
> Do a 'break;' for consistency's sake?
> 

Would an out_err label be okay ?

> >          }
> > 
> >          iov_cnt = elem->out_num;
> >   
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 13:44   ` Greg Kurz
  2016-09-21 14:01     ` Fam Zheng
@ 2016-09-21 17:35     ` Michael S. Tsirkin
  2016-09-21 18:12       ` Greg Kurz
  1 sibling, 1 reply; 34+ messages in thread
From: Michael S. Tsirkin @ 2016-09-21 17:35 UTC (permalink / raw)
  To: Greg Kurz
  Cc: no-reply, famz, qemu-devel, kwolf, jasowang, mreitz,
	aneesh.kumar, stefanha, cornelia.huck, pbonzini

On Wed, Sep 21, 2016 at 03:44:33PM +0200, Greg Kurz wrote:
> On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
> no-reply@patchew.org wrote:
> 
> > Hi,
> > 
> > Your series failed automatic build test. Please find the testing commands and
> > their output below. If you have docker installed, you can probably reproduce it
> > locally.
> > 
> 
> Heh... of course patchew doesn't know about Stefan's series. :)
> 
> Is there an appropriate way to avoid complaints when sending a patchset that
> isn't based on QEMU master ?

It's a good idea to be explicit which tree does the patchset
target, and on top of which patches it is applied.

qemu master is kind of the default, but even then it's
a good idea to tell everyone which hash it was based on -
imagine someone trying to use your patchset several years from now.

-- 
MST

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 14:01     ` Fam Zheng
  2016-09-21 14:29       ` Eric Blake
  2016-09-21 14:34       ` Greg Kurz
@ 2016-09-21 17:38       ` Michael S. Tsirkin
  2 siblings, 0 replies; 34+ messages in thread
From: Michael S. Tsirkin @ 2016-09-21 17:38 UTC (permalink / raw)
  To: Fam Zheng
  Cc: Greg Kurz, qemu-devel, kwolf, jasowang, mreitz, aneesh.kumar,
	stefanha, cornelia.huck, pbonzini

On Wed, Sep 21, 2016 at 10:01:30PM +0800, Fam Zheng wrote:
> On Wed, 09/21 15:44, Greg Kurz wrote:
> > On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
> > no-reply@patchew.org wrote:
> > 
> > > Hi,
> > > 
> > > Your series failed automatic build test. Please find the testing commands and
> > > their output below. If you have docker installed, you can probably reproduce it
> > > locally.
> > > 
> > 
> > Heh... of course patchew doesn't know about Stefan's series. :)
> 
> Usually those patchsets fail to apply and patchew keeps quiet. This series is
> the first victim of a exception, seemingly. :)
> > 
> > Is there an appropriate way to avoid complaints when sending a patchset that
> > isn't based on QEMU master ?
> 
> Currently we don't, but we can invent one. Like:
> 
> Base: http://github.com/someone/qemu branch
> 
> for the "base on maintainer tree" case, or just inform patchew to "pull"
> instead of apply:
> 
> Git: http://github.com/someone/qemu topic
> 
> for the "base on the other series" case.
> 
> Supporting this is not complicated, the tricky thing is to remember to put that
> magic in cover letters every time a series doesn't base on master.

Including the message id of the base series is being nice to humans, not
just the robots. I mean Stefan does a lot of work, merely saying
"follow up to Stefan's work" isn't really sufficient.

> 
> Any thoughts on the harder question? :)
> 
> Fam

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 17:35     ` Michael S. Tsirkin
@ 2016-09-21 18:12       ` Greg Kurz
  0 siblings, 0 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-21 18:12 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: no-reply, famz, qemu-devel, kwolf, jasowang, mreitz,
	aneesh.kumar, stefanha, cornelia.huck, pbonzini

On Wed, 21 Sep 2016 20:35:49 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Wed, Sep 21, 2016 at 03:44:33PM +0200, Greg Kurz wrote:
> > On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
> > no-reply@patchew.org wrote:
> >   
> > > Hi,
> > > 
> > > Your series failed automatic build test. Please find the testing commands and
> > > their output below. If you have docker installed, you can probably reproduce it
> > > locally.
> > >   
> > 
> > Heh... of course patchew doesn't know about Stefan's series. :)
> > 
> > Is there an appropriate way to avoid complaints when sending a patchset that
> > isn't based on QEMU master ?  
> 
> It's a good idea to be explicit which tree does the patchset
> target, and on top of which patches it is applied.
> 

I thought that referring to the current patchset to eradicate exit() from the
virtio code was enough. But I agree it isn't that explicit.

> qemu master is kind of the default, but even then it's
> a good idea to tell everyone which hash it was based on -
> imagine someone trying to use your patchset several years from now.
> 

I understand. I'll try to remember that next time. In the case of a
patchset which isn't committed yet, I like the suggestion to put
the Message-Id you made in another mail.

Cheers.

--
Greg

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
                   ` (7 preceding siblings ...)
  2016-09-21 13:35 ` [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination no-reply
@ 2016-09-22  1:19 ` Gonglei
  2016-09-22  6:43   ` Greg Kurz
  8 siblings, 1 reply; 34+ messages in thread
From: Gonglei @ 2016-09-22  1:19 UTC (permalink / raw)
  To: Greg Kurz, qemu-devel
  Cc: Kevin Wolf, Michael S. Tsirkin, Jason Wang, Max Reitz,
	Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck, Paolo Bonzini



On 2016/9/21 21:13, Greg Kurz wrote:
> This series is a follow up to Stefan's work to eradicate most calls to
> exit() we currently have in the virtio code.
> 
> It addresses all exit() call sites in the blk, net and scsi device code,
> where the error is about a missing or malformed in/out header sent by
> the guest. They are converted to use virtio_error() and stop any processing,
> instead of exiting.
> 
Actually if you just stop procesing when encounter a missing in/out header but
send a interrupt to the guest, the guest maybe be stuck. virtio_net_handle_ctrl()
is an example, the guest frontend driver infinite loop to wait the interrupt's coming.
The guest can't work anymore though you don't exit the Qemu process .

Regards,
-Gonglei

> The remaining call sites are related to a host misconfiguration or a
> migration stream issue.
> 
> The 9P code currently calls assert() instead of exit(), but it also about
> malformed or missing headers, so it gets converted the same way.
> 
> Next work will be to check all assert() call sites in the device code, in
> case some of them actually refer to a bug in the guest, and should be
> converted to use virtio_error() as well.
> 
> ---
> 
> Greg Kurz (7):
>       virtio-9p: handle handle_9p_output() error
>       virtio-blk: handle virtio_blk_handle_request() errors
>       virtio-net: handle virtio_net_handle_ctrl() error
>       virtio-net: handle virtio_net_receive() errors
>       virtio-net: handle virtio_net_flush_tx() errors
>       virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
>       virtio-scsi: handle virtio_scsi_set_config() error
> 
> 
>  hw/9pfs/virtio-9p-device.c |   14 ++++++++++--
>  hw/block/virtio-blk.c      |   27 +++++++++++++++--------
>  hw/net/virtio-net.c        |   51 +++++++++++++++++++++++++-------------------
>  hw/scsi/virtio-scsi.c      |   21 ++++++++++--------
>  4 files changed, 70 insertions(+), 43 deletions(-)
> 
> --
> Greg
> 
> 
> 
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-21 14:29       ` Eric Blake
@ 2016-09-22  5:39         ` Fam Zheng
  0 siblings, 0 replies; 34+ messages in thread
From: Fam Zheng @ 2016-09-22  5:39 UTC (permalink / raw)
  To: Eric Blake
  Cc: Greg Kurz, kwolf, mst, jasowang, qemu-devel, mreitz,
	aneesh.kumar, stefanha, cornelia.huck, pbonzini

On Wed, 09/21 09:29, Eric Blake wrote:
> On 09/21/2016 09:01 AM, Fam Zheng wrote:
> > On Wed, 09/21 15:44, Greg Kurz wrote:
> >> On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
> >> no-reply@patchew.org wrote:
> >>
> >>> Hi,
> >>>
> >>> Your series failed automatic build test. Please find the testing commands and
> >>> their output below. If you have docker installed, you can probably reproduce it
> >>> locally.
> >>>
> >>
> >> Heh... of course patchew doesn't know about Stefan's series. :)
> > 
> > Usually those patchsets fail to apply and patchew keeps quiet. This series is
> > the first victim of a exception, seemingly. :)
> 
> While we're at it, is there a way to make the error messages include the
> last 15 lines or so of the build log first, and then the full build log?
>  Usually, the failure is easy to identify from the tail of the message,
> but having to scroll to the bottom past all the successful portion of
> the log is slower than seeing the tail up front.  At the same time, the
> full log is useful for the cases where the failure occurs earlier than
> the last 15 lines.

Scrolling to bottom is quite easy in any email client, while more sections in a
long email demand extra effort to manage and read. I doubt adding a "tail of
log" section just before the full log helps us much. I'd rather keep it simple
and stupid.

> 
> > 
> >>
> >> Is there an appropriate way to avoid complaints when sending a patchset that
> >> isn't based on QEMU master ?
> > 
> > Currently we don't, but we can invent one. Like:
> > 
> > Base: http://github.com/someone/qemu branch
> 
> I like that idea (these patches apply from that point; then it is up to
> patchew whether to bother chasing down that point or just skipping the
> series)
> 
> > 
> > for the "base on maintainer tree" case, or just inform patchew to "pull"
> > instead of apply:
> > 
> > Git: http://github.com/someone/qemu topic
> 
> Maybe Pull: instead of Git:, but again a nice idea.

I'm adding them to my list.

> 
> 
> > 
> > for the "base on the other series" case.
> > 
> > Supporting this is not complicated, the tricky thing is to remember to put that
> > magic in cover letters every time a series doesn't base on master.
> > 
> > Any thoughts on the harder question? :)
> 
> Which one was the harder question? How to get people to remember to use
> magic that patchew can recognize?

Yes. :)


> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-22  1:19 ` Gonglei
@ 2016-09-22  6:43   ` Greg Kurz
  2016-09-22  6:55     ` Gonglei (Arei)
  0 siblings, 1 reply; 34+ messages in thread
From: Greg Kurz @ 2016-09-22  6:43 UTC (permalink / raw)
  To: Gonglei
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck,
	Paolo Bonzini

On Thu, 22 Sep 2016 09:19:49 +0800
Gonglei <arei.gonglei@huawei.com> wrote:

> On 2016/9/21 21:13, Greg Kurz wrote:
> > This series is a follow up to Stefan's work to eradicate most calls to
> > exit() we currently have in the virtio code.
> > 
> > It addresses all exit() call sites in the blk, net and scsi device code,
> > where the error is about a missing or malformed in/out header sent by
> > the guest. They are converted to use virtio_error() and stop any processing,
> > instead of exiting.
> >   
> Actually if you just stop procesing when encounter a missing in/out header but
> send a interrupt to the guest, the guest maybe be stuck. virtio_net_handle_ctrl()

The virtio_error() function sets the device status to DEVICE_NEEDS_RESET and
does send a device configuration change interrupt to the guest, so it can take
appropriate action (i.e. reset the device).

Maybe I should have mentioned that in the changelog...

Cheers.

--
Greg

> is an example, the guest frontend driver infinite loop to wait the interrupt's coming.
> The guest can't work anymore though you don't exit the Qemu process .
> 
> Regards,
> -Gonglei
> 
> > The remaining call sites are related to a host misconfiguration or a
> > migration stream issue.
> > 
> > The 9P code currently calls assert() instead of exit(), but it also about
> > malformed or missing headers, so it gets converted the same way.
> > 
> > Next work will be to check all assert() call sites in the device code, in
> > case some of them actually refer to a bug in the guest, and should be
> > converted to use virtio_error() as well.
> > 
> > ---
> > 
> > Greg Kurz (7):
> >       virtio-9p: handle handle_9p_output() error
> >       virtio-blk: handle virtio_blk_handle_request() errors
> >       virtio-net: handle virtio_net_handle_ctrl() error
> >       virtio-net: handle virtio_net_receive() errors
> >       virtio-net: handle virtio_net_flush_tx() errors
> >       virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> >       virtio-scsi: handle virtio_scsi_set_config() error
> > 
> > 
> >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++--
> >  hw/block/virtio-blk.c      |   27 +++++++++++++++--------
> >  hw/net/virtio-net.c        |   51 +++++++++++++++++++++++++-------------------
> >  hw/scsi/virtio-scsi.c      |   21 ++++++++++--------
> >  4 files changed, 70 insertions(+), 43 deletions(-)
> > 
> > --
> > Greg
> > 
> > 
> > 
> >   
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-22  6:43   ` Greg Kurz
@ 2016-09-22  6:55     ` Gonglei (Arei)
  2016-09-22  7:21       ` Greg Kurz
  0 siblings, 1 reply; 34+ messages in thread
From: Gonglei (Arei) @ 2016-09-22  6:55 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck,
	Paolo Bonzini


> -----Original Message-----
> From: Greg Kurz [mailto:groug@kaod.org]
> Sent: Thursday, September 22, 2016 2:43 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> termination
> 
> On Thu, 22 Sep 2016 09:19:49 +0800
> Gonglei <arei.gonglei@huawei.com> wrote:
> 
> > On 2016/9/21 21:13, Greg Kurz wrote:
> > > This series is a follow up to Stefan's work to eradicate most calls to
> > > exit() we currently have in the virtio code.
> > >
> > > It addresses all exit() call sites in the blk, net and scsi device code,
> > > where the error is about a missing or malformed in/out header sent by
> > > the guest. They are converted to use virtio_error() and stop any processing,
> > > instead of exiting.
> > >
> > Actually if you just stop procesing when encounter a missing in/out header
> but
> > send a interrupt to the guest, the guest maybe be stuck.
> virtio_net_handle_ctrl()
> 
> The virtio_error() function sets the device status to DEVICE_NEEDS_RESET and
> does send a device configuration change interrupt to the guest, so it can take
> appropriate action (i.e. reset the device).
> 
That's appropriate. Where is realization of virtio_error() ? 
I'm sure I missed something. 
 
Regards,
-Gonglei

> Maybe I should have mentioned that in the changelog...
> 
> Cheers.
> 
> --
> Greg
> 
> > is an example, the guest frontend driver infinite loop to wait the interrupt's
> coming.
> > The guest can't work anymore though you don't exit the Qemu process .
> >
> > Regards,
> > -Gonglei
> >
> > > The remaining call sites are related to a host misconfiguration or a
> > > migration stream issue.
> > >
> > > The 9P code currently calls assert() instead of exit(), but it also about
> > > malformed or missing headers, so it gets converted the same way.
> > >
> > > Next work will be to check all assert() call sites in the device code, in
> > > case some of them actually refer to a bug in the guest, and should be
> > > converted to use virtio_error() as well.
> > >
> > > ---
> > >
> > > Greg Kurz (7):
> > >       virtio-9p: handle handle_9p_output() error
> > >       virtio-blk: handle virtio_blk_handle_request() errors
> > >       virtio-net: handle virtio_net_handle_ctrl() error
> > >       virtio-net: handle virtio_net_receive() errors
> > >       virtio-net: handle virtio_net_flush_tx() errors
> > >       virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> > >       virtio-scsi: handle virtio_scsi_set_config() error
> > >
> > >
> > >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++--
> > >  hw/block/virtio-blk.c      |   27 +++++++++++++++--------
> > >  hw/net/virtio-net.c        |   51
> +++++++++++++++++++++++++-------------------
> > >  hw/scsi/virtio-scsi.c      |   21 ++++++++++--------
> > >  4 files changed, 70 insertions(+), 43 deletions(-)
> > >
> > > --
> > > Greg
> > >
> > >
> > >
> > >
> >

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-22  6:55     ` Gonglei (Arei)
@ 2016-09-22  7:21       ` Greg Kurz
  2016-09-22  7:30         ` Gonglei (Arei)
  2016-09-22  7:38         ` Gonglei (Arei)
  0 siblings, 2 replies; 34+ messages in thread
From: Greg Kurz @ 2016-09-22  7:21 UTC (permalink / raw)
  To: Gonglei (Arei)
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck,
	Paolo Bonzini

On Thu, 22 Sep 2016 06:55:43 +0000
"Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:

> > -----Original Message-----
> > From: Greg Kurz [mailto:groug@kaod.org]
> > Sent: Thursday, September 22, 2016 2:43 PM
> > To: Gonglei (Arei)
> > Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> > Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> > Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> > termination
> > 
> > On Thu, 22 Sep 2016 09:19:49 +0800
> > Gonglei <arei.gonglei@huawei.com> wrote:
> >   
> > > On 2016/9/21 21:13, Greg Kurz wrote:  
> > > > This series is a follow up to Stefan's work to eradicate most calls to
> > > > exit() we currently have in the virtio code.
> > > >
> > > > It addresses all exit() call sites in the blk, net and scsi device code,
> > > > where the error is about a missing or malformed in/out header sent by
> > > > the guest. They are converted to use virtio_error() and stop any processing,
> > > > instead of exiting.
> > > >  
> > > Actually if you just stop procesing when encounter a missing in/out header  
> > but  
> > > send a interrupt to the guest, the guest maybe be stuck.  
> > virtio_net_handle_ctrl()
> > 
> > The virtio_error() function sets the device status to DEVICE_NEEDS_RESET and
> > does send a device configuration change interrupt to the guest, so it can take
> > appropriate action (i.e. reset the device).
> >   
> That's appropriate. Where is realization of virtio_error() ? 
> I'm sure I missed something. 
> 

Sorry for that... Michael already "lectured" me about not providing these
details. He is right indeed :)


This is work in progress by Stefan. The latest version of the patchset (v5) was
posted yesterday:

<1474473146-19337-1-git-send-email-stefanha@redhat.com>

The virtio_error() function itself is in patch 2/9:

<1474473146-19337-3-git-send-email-stefanha@redhat.com>

Cheers.

--
Greg

> Regards,
> -Gonglei
> 
> > Maybe I should have mentioned that in the changelog...
> > 
> > Cheers.
> > 
> > --
> > Greg
> >   
> > > is an example, the guest frontend driver infinite loop to wait the interrupt's  
> > coming.  
> > > The guest can't work anymore though you don't exit the Qemu process .
> > >
> > > Regards,
> > > -Gonglei
> > >  
> > > > The remaining call sites are related to a host misconfiguration or a
> > > > migration stream issue.
> > > >
> > > > The 9P code currently calls assert() instead of exit(), but it also about
> > > > malformed or missing headers, so it gets converted the same way.
> > > >
> > > > Next work will be to check all assert() call sites in the device code, in
> > > > case some of them actually refer to a bug in the guest, and should be
> > > > converted to use virtio_error() as well.
> > > >
> > > > ---
> > > >
> > > > Greg Kurz (7):
> > > >       virtio-9p: handle handle_9p_output() error
> > > >       virtio-blk: handle virtio_blk_handle_request() errors
> > > >       virtio-net: handle virtio_net_handle_ctrl() error
> > > >       virtio-net: handle virtio_net_receive() errors
> > > >       virtio-net: handle virtio_net_flush_tx() errors
> > > >       virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> > > >       virtio-scsi: handle virtio_scsi_set_config() error
> > > >
> > > >
> > > >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++--
> > > >  hw/block/virtio-blk.c      |   27 +++++++++++++++--------
> > > >  hw/net/virtio-net.c        |   51  
> > +++++++++++++++++++++++++-------------------  
> > > >  hw/scsi/virtio-scsi.c      |   21 ++++++++++--------
> > > >  4 files changed, 70 insertions(+), 43 deletions(-)
> > > >
> > > > --
> > > > Greg
> > > >
> > > >
> > > >
> > > >  
> > >  
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-22  7:21       ` Greg Kurz
@ 2016-09-22  7:30         ` Gonglei (Arei)
  2016-09-22  7:38         ` Gonglei (Arei)
  1 sibling, 0 replies; 34+ messages in thread
From: Gonglei (Arei) @ 2016-09-22  7:30 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck,
	Paolo Bonzini


> -----Original Message-----
> From: Greg Kurz [mailto:groug@kaod.org]
> Sent: Thursday, September 22, 2016 3:22 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> termination
> 
> On Thu, 22 Sep 2016 06:55:43 +0000
> "Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:
> 
> > > -----Original Message-----
> > > From: Greg Kurz [mailto:groug@kaod.org]
> > > Sent: Thursday, September 22, 2016 2:43 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang;
> Max
> > > Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> > > Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> > > termination
> > >
> > > On Thu, 22 Sep 2016 09:19:49 +0800
> > > Gonglei <arei.gonglei@huawei.com> wrote:
> > >
> > > > On 2016/9/21 21:13, Greg Kurz wrote:
> > > > > This series is a follow up to Stefan's work to eradicate most calls to
> > > > > exit() we currently have in the virtio code.
> > > > >
> > > > > It addresses all exit() call sites in the blk, net and scsi device code,
> > > > > where the error is about a missing or malformed in/out header sent by
> > > > > the guest. They are converted to use virtio_error() and stop any
> processing,
> > > > > instead of exiting.
> > > > >
> > > > Actually if you just stop procesing when encounter a missing in/out header
> > > but
> > > > send a interrupt to the guest, the guest maybe be stuck.
> > > virtio_net_handle_ctrl()
> > >
> > > The virtio_error() function sets the device status to DEVICE_NEEDS_RESET
> and
> > > does send a device configuration change interrupt to the guest, so it can
> take
> > > appropriate action (i.e. reset the device).
> > >
> > That's appropriate. Where is realization of virtio_error() ?
> > I'm sure I missed something.
> >
> 
> Sorry for that... Michael already "lectured" me about not providing these
> details. He is right indeed :)
> 
> 
> This is work in progress by Stefan. The latest version of the patchset (v5) was
> posted yesterday:
> 
> <1474473146-19337-1-git-send-email-stefanha@redhat.com>
> 
> The virtio_error() function itself is in patch 2/9:
> 
> <1474473146-19337-3-git-send-email-stefanha@redhat.com>
> 

I see, thanks.

Regards,
-Gonglei

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-22  7:21       ` Greg Kurz
  2016-09-22  7:30         ` Gonglei (Arei)
@ 2016-09-22  7:38         ` Gonglei (Arei)
  2016-09-22  8:14           ` Greg Kurz
  1 sibling, 1 reply; 34+ messages in thread
From: Gonglei (Arei) @ 2016-09-22  7:38 UTC (permalink / raw)
  To: Greg Kurz
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck,
	Paolo Bonzini

Hi Greg,



> -----Original Message-----
> From: Greg Kurz [mailto:groug@kaod.org]
> Sent: Thursday, September 22, 2016 3:22 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> termination
> 
> On Thu, 22 Sep 2016 06:55:43 +0000
> "Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:
> 
> > > -----Original Message-----
> > > From: Greg Kurz [mailto:groug@kaod.org]
> > > Sent: Thursday, September 22, 2016 2:43 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang;
> Max
> > > Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> > > Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> > > termination
> > >
> > > On Thu, 22 Sep 2016 09:19:49 +0800
> > > Gonglei <arei.gonglei@huawei.com> wrote:
> > >
> > > > On 2016/9/21 21:13, Greg Kurz wrote:
> > > > > This series is a follow up to Stefan's work to eradicate most calls to
> > > > > exit() we currently have in the virtio code.
> > > > >
> > > > > It addresses all exit() call sites in the blk, net and scsi device code,
> > > > > where the error is about a missing or malformed in/out header sent by
> > > > > the guest. They are converted to use virtio_error() and stop any
> processing,
> > > > > instead of exiting.
> > > > >
> > > > Actually if you just stop procesing when encounter a missing in/out header
> > > but
> > > > send a interrupt to the guest, the guest maybe be stuck.
> > > virtio_net_handle_ctrl()
> > >
> > > The virtio_error() function sets the device status to DEVICE_NEEDS_RESET
> and
> > > does send a device configuration change interrupt to the guest, so it can
> take
> > > appropriate action (i.e. reset the device).
> > >

I saw virtio_error() only handle the virtio 1.0 device, the legacy virtio device may
still stuck, am I right?

+void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    error_vreport(fmt, ap);
+    va_end(ap);
+
+    vdev->broken = true;
+
+    if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+        virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
+        virtio_notify_config(vdev);
+    }
+}


Regards,
-Gonglei

> > That's appropriate. Where is realization of virtio_error() ?
> > I'm sure I missed something.
> >
> 
> Sorry for that... Michael already "lectured" me about not providing these
> details. He is right indeed :)
> 
> 
> This is work in progress by Stefan. The latest version of the patchset (v5) was
> posted yesterday:
> 
> <1474473146-19337-1-git-send-email-stefanha@redhat.com>
> 
> The virtio_error() function itself is in patch 2/9:
> 
> <1474473146-19337-3-git-send-email-stefanha@redhat.com>
> 
> Cheers.
> 
> --
> Greg
> 
> > Regards,
> > -Gonglei
> >
> > > Maybe I should have mentioned that in the changelog...
> > >
> > > Cheers.
> > >
> > > --
> > > Greg
> > >
> > > > is an example, the guest frontend driver infinite loop to wait the
> interrupt's
> > > coming.
> > > > The guest can't work anymore though you don't exit the Qemu process .
> > > >
> > > > Regards,
> > > > -Gonglei
> > > >
> > > > > The remaining call sites are related to a host misconfiguration or a
> > > > > migration stream issue.
> > > > >
> > > > > The 9P code currently calls assert() instead of exit(), but it also about
> > > > > malformed or missing headers, so it gets converted the same way.
> > > > >
> > > > > Next work will be to check all assert() call sites in the device code, in
> > > > > case some of them actually refer to a bug in the guest, and should be
> > > > > converted to use virtio_error() as well.
> > > > >
> > > > > ---
> > > > >
> > > > > Greg Kurz (7):
> > > > >       virtio-9p: handle handle_9p_output() error
> > > > >       virtio-blk: handle virtio_blk_handle_request() errors
> > > > >       virtio-net: handle virtio_net_handle_ctrl() error
> > > > >       virtio-net: handle virtio_net_receive() errors
> > > > >       virtio-net: handle virtio_net_flush_tx() errors
> > > > >       virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> > > > >       virtio-scsi: handle virtio_scsi_set_config() error
> > > > >
> > > > >
> > > > >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++--
> > > > >  hw/block/virtio-blk.c      |   27 +++++++++++++++--------
> > > > >  hw/net/virtio-net.c        |   51
> > > +++++++++++++++++++++++++-------------------
> > > > >  hw/scsi/virtio-scsi.c      |   21 ++++++++++--------
> > > > >  4 files changed, 70 insertions(+), 43 deletions(-)
> > > > >
> > > > > --
> > > > > Greg
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-22  7:38         ` Gonglei (Arei)
@ 2016-09-22  8:14           ` Greg Kurz
  2016-09-22  8:28             ` Cornelia Huck
  0 siblings, 1 reply; 34+ messages in thread
From: Greg Kurz @ 2016-09-22  8:14 UTC (permalink / raw)
  To: Gonglei (Arei)
  Cc: qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Cornelia Huck,
	Paolo Bonzini

On Thu, 22 Sep 2016 07:38:29 +0000
"Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:

> Hi Greg,
> 
> 
> 
> > -----Original Message-----
> > From: Greg Kurz [mailto:groug@kaod.org]
> > Sent: Thursday, September 22, 2016 3:22 PM
> > To: Gonglei (Arei)
> > Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> > Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> > Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> > termination
> > 
> > On Thu, 22 Sep 2016 06:55:43 +0000
> > "Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:
> >   
> > > > -----Original Message-----
> > > > From: Greg Kurz [mailto:groug@kaod.org]
> > > > Sent: Thursday, September 22, 2016 2:43 PM
> > > > To: Gonglei (Arei)
> > > > Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang;  
> > Max  
> > > > Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> > > > Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> > > > termination
> > > >
> > > > On Thu, 22 Sep 2016 09:19:49 +0800
> > > > Gonglei <arei.gonglei@huawei.com> wrote:
> > > >  
> > > > > On 2016/9/21 21:13, Greg Kurz wrote:  
> > > > > > This series is a follow up to Stefan's work to eradicate most calls to
> > > > > > exit() we currently have in the virtio code.
> > > > > >
> > > > > > It addresses all exit() call sites in the blk, net and scsi device code,
> > > > > > where the error is about a missing or malformed in/out header sent by
> > > > > > the guest. They are converted to use virtio_error() and stop any  
> > processing,  
> > > > > > instead of exiting.
> > > > > >  
> > > > > Actually if you just stop procesing when encounter a missing in/out header  
> > > > but  
> > > > > send a interrupt to the guest, the guest maybe be stuck.  
> > > > virtio_net_handle_ctrl()
> > > >
> > > > The virtio_error() function sets the device status to DEVICE_NEEDS_RESET  
> > and  
> > > > does send a device configuration change interrupt to the guest, so it can  
> > take  
> > > > appropriate action (i.e. reset the device).
> > > >  
> 
> I saw virtio_error() only handle the virtio 1.0 device, the legacy virtio device may
> still stuck, am I right?
> 

The DEVICE_NEEDS_RESET bit was introduced by the virtio 1.0 specification.

http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-100001

Yes, the legacy device will stay stuck since the broken flag is set.

Cheers.

--
Greg

> +void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, ...)
> +{
> +    va_list ap;
> +
> +    va_start(ap, fmt);
> +    error_vreport(fmt, ap);
> +    va_end(ap);
> +
> +    vdev->broken = true;
> +
> +    if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> +        virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
> +        virtio_notify_config(vdev);
> +    }
> +}
> 
> 
> Regards,
> -Gonglei
> 
> > > That's appropriate. Where is realization of virtio_error() ?
> > > I'm sure I missed something.
> > >  
> > 
> > Sorry for that... Michael already "lectured" me about not providing these
> > details. He is right indeed :)
> > 
> > 
> > This is work in progress by Stefan. The latest version of the patchset (v5) was
> > posted yesterday:
> > 
> > <1474473146-19337-1-git-send-email-stefanha@redhat.com>
> > 
> > The virtio_error() function itself is in patch 2/9:
> > 
> > <1474473146-19337-3-git-send-email-stefanha@redhat.com>
> > 
> > Cheers.
> > 
> > --
> > Greg
> >   
> > > Regards,
> > > -Gonglei
> > >  
> > > > Maybe I should have mentioned that in the changelog...
> > > >
> > > > Cheers.
> > > >
> > > > --
> > > > Greg
> > > >  
> > > > > is an example, the guest frontend driver infinite loop to wait the  
> > interrupt's  
> > > > coming.  
> > > > > The guest can't work anymore though you don't exit the Qemu process .
> > > > >
> > > > > Regards,
> > > > > -Gonglei
> > > > >  
> > > > > > The remaining call sites are related to a host misconfiguration or a
> > > > > > migration stream issue.
> > > > > >
> > > > > > The 9P code currently calls assert() instead of exit(), but it also about
> > > > > > malformed or missing headers, so it gets converted the same way.
> > > > > >
> > > > > > Next work will be to check all assert() call sites in the device code, in
> > > > > > case some of them actually refer to a bug in the guest, and should be
> > > > > > converted to use virtio_error() as well.
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > Greg Kurz (7):
> > > > > >       virtio-9p: handle handle_9p_output() error
> > > > > >       virtio-blk: handle virtio_blk_handle_request() errors
> > > > > >       virtio-net: handle virtio_net_handle_ctrl() error
> > > > > >       virtio-net: handle virtio_net_receive() errors
> > > > > >       virtio-net: handle virtio_net_flush_tx() errors
> > > > > >       virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> > > > > >       virtio-scsi: handle virtio_scsi_set_config() error
> > > > > >
> > > > > >
> > > > > >  hw/9pfs/virtio-9p-device.c |   14 ++++++++++--
> > > > > >  hw/block/virtio-blk.c      |   27 +++++++++++++++--------
> > > > > >  hw/net/virtio-net.c        |   51  
> > > > +++++++++++++++++++++++++-------------------  
> > > > > >  hw/scsi/virtio-scsi.c      |   21 ++++++++++--------
> > > > > >  4 files changed, 70 insertions(+), 43 deletions(-)
> > > > > >
> > > > > > --
> > > > > > Greg
> > > > > >
> > > > > >
> > > > > >
> > > > > >  
> > > > >  
> > >  
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
  2016-09-22  8:14           ` Greg Kurz
@ 2016-09-22  8:28             ` Cornelia Huck
  0 siblings, 0 replies; 34+ messages in thread
From: Cornelia Huck @ 2016-09-22  8:28 UTC (permalink / raw)
  To: Greg Kurz
  Cc: Gonglei (Arei),
	qemu-devel, Kevin Wolf, Michael S. Tsirkin, Jason Wang,
	Max Reitz, Aneesh Kumar K.V, Stefan Hajnoczi, Paolo Bonzini

On Thu, 22 Sep 2016 10:14:56 +0200
Greg Kurz <groug@kaod.org> wrote:

> On Thu, 22 Sep 2016 07:38:29 +0000
> "Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:

> > I saw virtio_error() only handle the virtio 1.0 device, the legacy virtio device may
> > still stuck, am I right?
> > 
> 
> The DEVICE_NEEDS_RESET bit was introduced by the virtio 1.0 specification.
> 
> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-100001
> 
> Yes, the legacy device will stay stuck since the broken flag is set.

Yes, I fear there's nothing we can do to handle legacy devices
gracefully. If one broken device doesn't drag down the rest of the
machine with it, it's still a net win, I think.

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2016-09-22  8:28 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error Greg Kurz
2016-09-21 14:16   ` Cornelia Huck
2016-09-21 14:38     ` Greg Kurz
2016-09-21 14:43       ` Cornelia Huck
2016-09-21 14:42     ` Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors Greg Kurz
2016-09-21 14:28   ` Cornelia Huck
2016-09-21 15:01     ` Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error Greg Kurz
2016-09-21 14:30   ` Cornelia Huck
2016-09-21 15:03     ` Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 4/7] virtio-net: handle virtio_net_receive() errors Greg Kurz
2016-09-21 14:38   ` Cornelia Huck
2016-09-21 13:14 ` [Qemu-devel] [PATCH 5/7] virtio-net: handle virtio_net_flush_tx() errors Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 6/7] virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error() Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 7/7] virtio-scsi: handle virtio_scsi_set_config() error Greg Kurz
2016-09-21 13:35 ` [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination no-reply
2016-09-21 13:44   ` Greg Kurz
2016-09-21 14:01     ` Fam Zheng
2016-09-21 14:29       ` Eric Blake
2016-09-22  5:39         ` Fam Zheng
2016-09-21 14:34       ` Greg Kurz
2016-09-21 17:38       ` Michael S. Tsirkin
2016-09-21 17:35     ` Michael S. Tsirkin
2016-09-21 18:12       ` Greg Kurz
2016-09-22  1:19 ` Gonglei
2016-09-22  6:43   ` Greg Kurz
2016-09-22  6:55     ` Gonglei (Arei)
2016-09-22  7:21       ` Greg Kurz
2016-09-22  7:30         ` Gonglei (Arei)
2016-09-22  7:38         ` Gonglei (Arei)
2016-09-22  8:14           ` Greg Kurz
2016-09-22  8:28             ` Cornelia Huck

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.