From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Liu, Changpeng" <changpeng.liu@intel.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"marcandre.lureau@redhat.com" <marcandre.lureau@redhat.com>,
"felipe@nutanix.com" <felipe@nutanix.com>,
"Harris, James R" <james.r.harris@intel.com>
Subject: Re: [Qemu-devel] [PATCH v4 2/4] vhost-user-blk: introduce a new vhost-user-blk host device
Date: Mon, 23 Oct 2017 15:55:29 +0300 [thread overview]
Message-ID: <20171023155223-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <FF7FC980937D6342B9D289F5F3C7C2625B5D8EB6@SHSMSX103.ccr.corp.intel.com>
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 <changpeng.liu@intel.com>
> > Cc: qemu-devel@nongnu.org; pbonzini@redhat.com; mst@redhat.com;
> > marcandre.lureau@redhat.com; felipe@nutanix.com; Harris, James R
> > <james.r.harris@intel.com>
> > 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
next prev parent reply other threads:[~2017-10-23 12:55 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 5:24 [Qemu-devel] [PATCH v4 0/4] *** Introduce a new vhost-user-blk host device to Qemu *** Changpeng Liu
2017-10-19 5:24 ` [Qemu-devel] [PATCH v4 1/4] vhost-user: add new vhost user messages to support virtio config space Changpeng Liu
2017-10-19 11:37 ` Paolo Bonzini
2017-10-19 14:09 ` Stefan Hajnoczi
2017-10-19 15:36 ` Michael S. Tsirkin
2017-10-20 10:00 ` Stefan Hajnoczi
2017-10-23 4:47 ` Liu, Changpeng
2017-10-23 17:26 ` Stefan Hajnoczi
2017-10-24 0:52 ` Liu, Changpeng
2017-10-24 13:00 ` Stefan Hajnoczi
2017-10-19 15:39 ` Michael S. Tsirkin
2017-10-19 15:43 ` Paolo Bonzini
2017-10-19 17:43 ` Michael S. Tsirkin
2017-10-19 21:04 ` Paolo Bonzini
2017-10-20 0:27 ` Michael S. Tsirkin
2017-10-20 1:55 ` Liu, Changpeng
2017-10-20 2:12 ` Michael S. Tsirkin
2017-10-20 2:34 ` Liu, Changpeng
2017-10-19 5:24 ` [Qemu-devel] [PATCH v4 2/4] vhost-user-blk: introduce a new vhost-user-blk host device Changpeng Liu
2017-10-19 11:33 ` Paolo Bonzini
2017-10-20 1:38 ` Liu, Changpeng
2017-10-19 15:17 ` Stefan Hajnoczi
2017-10-20 1:47 ` Liu, Changpeng
2017-10-20 9:54 ` Stefan Hajnoczi
2017-10-23 4:26 ` Liu, Changpeng
2017-10-23 12:55 ` Michael S. Tsirkin [this message]
2017-10-24 0:40 ` Liu, Changpeng
2017-10-23 17:11 ` Stefan Hajnoczi
2017-10-24 0:44 ` Liu, Changpeng
2017-10-24 12:53 ` Stefan Hajnoczi
2017-10-25 1:34 ` Liu, Changpeng
2017-11-03 14:50 ` Stefan Hajnoczi
2017-10-19 5:24 ` [Qemu-devel] [PATCH v4 3/4] contrib/libvhost-user: enable virtio config space messages Changpeng Liu
2017-10-19 5:24 ` [Qemu-devel] [PATCH v4 4/4] contrib/vhost-user-blk: introduce a vhost-user-blk sample application Changpeng Liu
2017-10-19 11:43 ` Paolo Bonzini
2017-10-20 1:39 ` Liu, Changpeng
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=20171023155223-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=changpeng.liu@intel.com \
--cc=felipe@nutanix.com \
--cc=james.r.harris@intel.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/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).