From: Paolo Bonzini <pbonzini@redhat.com>
To: qemu-devel@nongnu.org
Cc: aliguori@us.ibm.com, mst@redhat.com
Subject: [Qemu-devel] [PATCH 1.1 1/4] virtio-blk: report non-zero status when failing SG_IO requests
Date: Wed, 16 May 2012 12:54:03 +0200 [thread overview]
Message-ID: <1337165646-28118-2-git-send-email-pbonzini@redhat.com> (raw)
In-Reply-To: <1337165646-28118-1-git-send-email-pbonzini@redhat.com>
Linux really looks only at scsi->errors for SG_IO requests; it does
not look at the virtio request status at all. Because of this, when
a SG_IO request is failed early with virtio_blk_req_complete(req,
VIRTIO_BLK_S_UNSUPP), without writing hdr.status, it will look like
a success to the guest.
This is their bug, but we can make it safe for older guests now by
forcing scsi->errors to have a non-zero value whenever a request
has to be failed.
But if we fix the bug in the guest driver, we will have another problem
because QEMU returns VIRTIO_BLK_S_IOERR if the status is non-zero, and
Linux translates that to -EIO. Rather, the guest should succeed the
request and pass the non-zero status via the userspace-provided SG_IO
structure. So, remove the case where virtio_blk_handle_scsi can
return VIRTIO_BLK_S_IOERR.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/virtio-blk.c | 51 +++++++++++++++++++++++----------------------------
1 file changed, 23 insertions(+), 28 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index d4bb400..7148572 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -145,20 +145,12 @@ static VirtIOBlockReq *virtio_blk_get_request(VirtIOBlock *s)
return req;
}
-#ifdef __linux__
static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
{
- struct sg_io_hdr hdr;
int ret;
- int status;
+ int status = VIRTIO_BLK_S_OK;
int i;
- if ((req->dev->vdev.guest_features & (1 << VIRTIO_BLK_F_SCSI)) == 0) {
- virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
- g_free(req);
- return;
- }
-
/*
* We require at least one output segment each for the virtio_blk_outhdr
* and the SCSI command block.
@@ -173,20 +165,26 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
}
/*
- * No support for bidirection commands yet.
+ * The scsi inhdr is placed in the second-to-last input segment, just
+ * before the regular inhdr.
*/
- if (req->elem.out_num > 2 && req->elem.in_num > 3) {
- virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
- g_free(req);
- return;
+ req->scsi = (void *)req->elem.in_sg[req->elem.in_num - 2].iov_base;
+
+ if ((req->dev->vdev.guest_features & (1 << VIRTIO_BLK_F_SCSI)) == 0) {
+ status = VIRTIO_BLK_S_UNSUPP;
+ goto fail;
}
/*
- * The scsi inhdr is placed in the second-to-last input segment, just
- * before the regular inhdr.
+ * No support for bidirection commands yet.
*/
- req->scsi = (void *)req->elem.in_sg[req->elem.in_num - 2].iov_base;
+ if (req->elem.out_num > 2 && req->elem.in_num > 3) {
+ status = VIRTIO_BLK_S_UNSUPP;
+ goto fail;
+ }
+#ifdef __linux__
+ struct sg_io_hdr hdr;
memset(&hdr, 0, sizeof(struct sg_io_hdr));
hdr.interface_id = 'S';
hdr.cmd_len = req->elem.out_sg[1].iov_len;
@@ -230,12 +228,7 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
ret = bdrv_ioctl(req->dev->bs, SG_IO, &hdr);
if (ret) {
status = VIRTIO_BLK_S_UNSUPP;
- hdr.status = ret;
- hdr.resid = hdr.dxfer_len;
- } else if (hdr.status) {
- status = VIRTIO_BLK_S_IOERR;
- } else {
- status = VIRTIO_BLK_S_OK;
+ goto fail;
}
/*
@@ -258,14 +251,16 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
virtio_blk_req_complete(req, status);
g_free(req);
-}
#else
-static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
-{
- virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
+ abort();
+#endif
+
+fail:
+ /* Just put anything nonzero so that the ioctl fails in the guest. */
+ stl_p(&req->scsi->errors, 255);
+ virtio_blk_req_complete(req, status);
g_free(req);
}
-#endif /* __linux__ */
typedef struct MultiReqBuffer {
BlockRequest blkreq[32];
--
1.7.10.1
next prev parent reply other threads:[~2012-05-16 10:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 10:54 [Qemu-devel] [PATCH 1.1 0/4] decouple VIRTIO_BLK_F_SCSI from SG_IO support Paolo Bonzini
2012-05-16 10:54 ` Paolo Bonzini [this message]
2012-05-16 10:54 ` [Qemu-devel] [PATCH 1.1 2/4] virtio-blk: blockdev_mark_auto_del is transport-independent Paolo Bonzini
2012-05-16 10:54 ` [Qemu-devel] [PATCH 1.1 3/4] virtio-blk: define VirtIOBlkConf Paolo Bonzini
2012-05-16 10:54 ` [Qemu-devel] [PATCH 1.1 4/4] virtio-blk: always enable VIRTIO_BLK_F_SCSI Paolo Bonzini
2012-05-21 15:56 ` [Qemu-devel] [PATCH 1.1 0/4] decouple VIRTIO_BLK_F_SCSI from SG_IO support Paolo Bonzini
2012-05-21 16:15 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1337165646-28118-2-git-send-email-pbonzini@redhat.com \
--to=pbonzini@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).