From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUuUq-0002kg-L1 for qemu-devel@nongnu.org; Fri, 19 Sep 2014 05:29:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUuUh-0003qV-Jk for qemu-devel@nongnu.org; Fri, 19 Sep 2014 05:28:56 -0400 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:40082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUuUh-0003ob-Cj for qemu-devel@nongnu.org; Fri, 19 Sep 2014 05:28:47 -0400 Received: by mail-wi0-f180.google.com with SMTP id ex7so2629876wid.13 for ; Fri, 19 Sep 2014 02:28:39 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <541BF741.9060807@redhat.com> Date: Fri, 19 Sep 2014 11:28:33 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1407303308-4615-1-git-send-email-famz@redhat.com> In-Reply-To: <1407303308-4615-1-git-send-email-famz@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [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: Fam Zheng , qemu-devel@nongnu.org Cc: kwolf@redhat.com, stefanha@redhat.com Il 06/08/2014 07:34, Fam Zheng ha scritto: > 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 > I'm applying the patches to scsi-next. However, please resubmit the last two with the review comments addressed. I'm only pushing them so that we don't both spend time rebasing the branch. Thanks, Paolo Thanks