From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35885)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <xjtuwjp@gmail.com>) id 1VaivO-0004Uv-7k
	for qemu-devel@nongnu.org; Mon, 28 Oct 2013 05:15:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <xjtuwjp@gmail.com>) id 1VaivF-0000vl-LP
	for qemu-devel@nongnu.org; Mon, 28 Oct 2013 05:15:50 -0400
Received: from mail-bk0-x229.google.com ([2a00:1450:4008:c01::229]:37634)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <xjtuwjp@gmail.com>) id 1VaivF-0000vc-5s
	for qemu-devel@nongnu.org; Mon, 28 Oct 2013 05:15:41 -0400
Received: by mail-bk0-f41.google.com with SMTP id na10so1671041bkb.14
	for <qemu-devel@nongnu.org>; Mon, 28 Oct 2013 02:15:39 -0700 (PDT)
Message-ID: <526E2B33.60907@gmail.com>
Date: Mon, 28 Oct 2013 10:15:31 +0100
From: Jack Wang <xjtuwjp@gmail.com>
MIME-Version: 1.0
References: <526A87E2.9020705@gmail.com>
In-Reply-To: <526A87E2.9020705@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] block io lost in the guest ,
	possible related to qemu?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>, Alexey Zaytsev <alexey.zaytsev@gmail.com>, Stefan Hajnoczi <stefanha@redhat.com>

Hello Kevin & Stefan

Any comments or wild guess about the bug?

Regards,
Jack

On 10/25/2013 05:01 PM, Jack Wang wrote:
> Hi Experts,
> 
> We've seen guest block io lost in a VM.any response will be helpful
> 
> environment is:
> guest os: Ubuntu 1304
> running busy database workload with xfs on a disk export with virtio-blk
> 
> the exported vdb has very high infight io over 300. Some times later a
> lot io process in D state, looks a lot requests is lost in below storage
> stack.
> 
> We're use qemu-kvm 1.0, host kernel 3.4.51
> 
> In qemu log of virtio-blk.c
> I found below commit, I wonder is it possible the workload generate some
> unknown reqests to qemu that lost in virtio_blk_handle_read?
> I do some fio test myself, I cann't generate so call unknown request type.
> 
> Any response will be helpful.
> 
> Jack
> 
> 
> commit 9e72c45033770b81b536ac6091e91807247cc25a
> Author: Alexey Zaytsev <alexey.zaytsev@gmail.com>
> Date:   Thu Dec 13 09:03:43 2012 +0200
> 
>     virtio-blk: Return UNSUPP for unknown request types
> 
>     Currently, all unknown requests are treated as VIRTIO_BLK_T_IN
> 
>     Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
>     Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> 
> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
> index 92c745a..df57b35 100644
> --- a/hw/virtio-blk.c
> +++ b/hw/virtio-blk.c
> @@ -398,10 +398,14 @@ static void
> virtio_blk_handle_request(VirtIOBlockReq *req,
>          qemu_iovec_init_external(&req->qiov, &req->elem.out_sg[1],
>                                   req->elem.out_num - 1);
>          virtio_blk_handle_write(req, mrb);
> -    } else {
> +    } else if (type == VIRTIO_BLK_T_IN || type == VIRTIO_BLK_T_BARRIER) {
> +        /* VIRTIO_BLK_T_IN is 0, so we can't just & it. */
>          qemu_iovec_init_external(&req->qiov, &req->elem.in_sg[0],
>                                   req->elem.in_num - 1);
>          virtio_blk_handle_read(req);
> +    } else {
> +        virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
> +        g_free(req);
>      }
>  }
>