From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e6cGa-0005nS-Lr for qemu-devel@nongnu.org; Mon, 23 Oct 2017 08:55:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e6cGW-0008Dy-PW for qemu-devel@nongnu.org; Mon, 23 Oct 2017 08:55:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58090) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e6cGW-0008Cd-Fy for qemu-devel@nongnu.org; Mon, 23 Oct 2017 08:55:36 -0400 Date: Mon, 23 Oct 2017 15:55:29 +0300 From: "Michael S. Tsirkin" Message-ID: <20171023155223-mutt-send-email-mst@kernel.org> References: <1508390650-19115-1-git-send-email-changpeng.liu@intel.com> <1508390650-19115-3-git-send-email-changpeng.liu@intel.com> <20171019151745.GH6205@stefanha-x1.localdomain> <20171020095435.GD21393@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v4 2/4] vhost-user-blk: introduce a new vhost-user-blk host device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Liu, Changpeng" Cc: Stefan Hajnoczi , "qemu-devel@nongnu.org" , "pbonzini@redhat.com" , "marcandre.lureau@redhat.com" , "felipe@nutanix.com" , "Harris, James R" On Mon, Oct 23, 2017 at 04:26:36AM +0000, Liu, Changpeng wrote: > > > > -----Original Message----- > > From: Stefan Hajnoczi [mailto:stefanha@gmail.com] > > Sent: Friday, October 20, 2017 5:55 PM > > To: Liu, Changpeng > > Cc: qemu-devel@nongnu.org; pbonzini@redhat.com; mst@redhat.com; > > marcandre.lureau@redhat.com; felipe@nutanix.com; Harris, James R > > > > Subject: Re: [PATCH v4 2/4] vhost-user-blk: introduce a new vhost-user-blk host > > device > > > > On Fri, Oct 20, 2017 at 01:47:58AM +0000, Liu, Changpeng wrote: > > > > > +static Property vhost_user_blk_properties[] = { > > > > > + DEFINE_PROP_CHR("chardev", VHostUserBlk, chardev), > > > > > + DEFINE_PROP_UINT16("num_queues", VHostUserBlk, num_queues, 1), > > > > > + DEFINE_PROP_UINT32("queue_size", VHostUserBlk, queue_size, 128), > > > > > + DEFINE_PROP_BIT64("f_size_max", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_SIZE_MAX, true), > > > > > + DEFINE_PROP_BIT64("f_sizemax", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_SIZE_MAX, true), > > > > > + DEFINE_PROP_BIT64("f_segmax", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_SEG_MAX, true), > > > > > + DEFINE_PROP_BIT64("f_geometry", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_GEOMETRY, true), > > > > > + DEFINE_PROP_BIT64("f_readonly", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_RO, false), > > > > > + DEFINE_PROP_BIT64("f_blocksize", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_BLK_SIZE, true), > > > > > + DEFINE_PROP_BIT64("f_topology", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_TOPOLOGY, true), > > > > > + DEFINE_PROP_BIT64("f_multiqueue", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_MQ, true), > > > > > + DEFINE_PROP_BIT64("f_flush", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_FLUSH, true), > > > > > + DEFINE_PROP_BIT64("f_barrier", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_BARRIER, false), > > > > > + DEFINE_PROP_BIT64("f_scsi", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_SCSI, false), > > > > > + DEFINE_PROP_BIT64("f_wce", VHostUserBlk, host_features, > > > > > + VIRTIO_BLK_F_WCE, false), > > > > > > > > Please explain how feature negotation works. The vhost-user slave > > > > advertises support features in the return value from > > > > VHOST_USER_GET_FEATURES. How does this additional feature mask work > > and > > > > why is it useful? > > > According to Paolo's previous comments, VIRTIO_BLK_F_WCE/ > > VIRTIO_BLK_F_SCSI/ VIRTIO_BLK_F_BARRIER > > > should be removed. Here I added all the feature flags just want to avoid the > > case that vhost-user slave target > > > can support but Qemu vhost block driver cannot support it. > > > > Please explain a bit more how these options can be used. > > > > When I looked at the vhost code it seemed like the vhost slave can > > report any feature bits it wishes (even things QEMU doesn't know about). > > What is the purpose of override some of the feature bits on the QEMU > > command-line? > Hi Stefan, > Here I added a switch which can override vhost-slave's feature bits, for example, vhost-slave reported `VIRTIO_BLK_F_RO`, > but Qemu vhost-master can disable it through command line when started the Qemu. Users don't need to change any > vhost-slave's code to disable this feature, and this is also aligned with vhost-scsi and vhost-net's implementation. Yes but I don't see these properties in virtio_blk_properties. Please make the names consistent at least when virtio-blk has them. I am pretty sure you don't want to expose e.g. _F_SCSI. > > Stefan