From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEtsK-0000wU-Lq for qemu-devel@nongnu.org; Wed, 06 Aug 2014 01:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEtsD-00010T-Fr for qemu-devel@nongnu.org; Wed, 06 Aug 2014 01:35:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEtsD-0000zd-7u for qemu-devel@nongnu.org; Wed, 06 Aug 2014 01:34:53 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s765Yo6K008530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 6 Aug 2014 01:34:51 -0400 From: Fam Zheng Date: Wed, 6 Aug 2014 13:34:58 +0800 Message-Id: <1407303308-4615-1-git-send-email-famz@redhat.com> Subject: [Qemu-devel] [RFC PATCH v2 00/10] virtio-scsi: Dataplane on single iothread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@redhat.com Hi all, This series adds "iothread" property to virtio-scsi in a way just similar to virtio-blk, and turns all scsi devices to run on top of it. Example: -object iothread,id=iothread-1 \ -device virtio-scsi-pci,id=virtio-scsi-bus-0,iothread=iothread-1 \ -drive file=guest.img,id=scsi-disk-1,if=none,cache=none,aio=native \ -device scsi-disk,lun=1,drive=scsi-disk-1,id=scsi-disk-1 It uses irqfd, ioeventfd and vring in a way just like virtio-blk does now. Please review the general approach and see if major points are missed in terms of thread safety and completeness of the moved things from original context to iothread context. Note that the used vring is not function complete compared to virtqueue implementation, because of its lacking of MMIO handling. So this is just an RFC. Migration hasn't been looked into yet, either. Assigning multiple iothreads is supposed to be worked on top of this as well, but it's not thoroughly planned yet. Thanks, Fam Fam Zheng (10): virtio: Compile vring code unconditionally virtio-scsi: Split virtio_scsi_handle_cmd_req from virtio_scsi_handle_cmd virtio-scsi: Split virtio_scsi_handle_ctrl_req from virtio_scsi_handle_ctrl virtio-scsi: Add VirtIOSCSIVring in VirtIOSCSIReq virtio-scsi: Make virtio_scsi_init_req public virtio-scsi: Make virtio_scsi_free_req public virtio-scsi: Make virtio_scsi_push_event public virtio-scsi: Add 'iothread' property to virtio-scsi-pci virtio-scsi-dataplane: Code to run virtio-scsi on iothread virtio-scsi: Hook up with dataplane hw/scsi/Makefile.objs | 2 +- hw/scsi/virtio-scsi-dataplane.c | 219 +++++++++++++++++++++++++++++++++ hw/scsi/virtio-scsi.c | 260 +++++++++++++++++++++++++--------------- hw/virtio/Makefile.objs | 2 +- hw/virtio/virtio-pci.c | 2 + include/hw/virtio/virtio-scsi.h | 65 ++++++++++ 6 files changed, 450 insertions(+), 100 deletions(-) create mode 100644 hw/scsi/virtio-scsi-dataplane.c -- 2.0.3