From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBM66-0006d7-7R for qemu-devel@nongnu.org; Mon, 28 Nov 2016 08:35:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBM61-0008GB-Ax for qemu-devel@nongnu.org; Mon, 28 Nov 2016 08:35:54 -0500 Received: from mga03.intel.com ([134.134.136.65]:35165) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBM61-0008Ek-0M for qemu-devel@nongnu.org; Mon, 28 Nov 2016 08:35:49 -0500 Message-ID: <583C32D4.9000600@intel.com> Date: Mon, 28 Nov 2016 21:36:20 +0800 From: Wei Wang MIME-Version: 1.0 References: <1479957659-141601-1-git-send-email-wei.w.wang@intel.com> <1479957659-141601-5-git-send-email-wei.w.wang@intel.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [virtio-comment] Re: [PATCH v2 4/4] spec/vhost-user: add VHOST_USER_PROTOCOL_F_VERSATILE_SLAVE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Cc: mst@redhat.com, stefanha@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, virtio-comment@lists.oasis-open.org On 11/28/2016 08:41 PM, Marc-André Lureau wrote: > Hi > > On Thu, Nov 24, 2016 at 7:20 AM Wei Wang > wrote: > > The VHOST_USER_PROTOCOL_F_VERSATILE_SLAVE protocol feature indicates > that the slave side implementation supports different types of > devices. > The master tells the slave what type of device to create by sending > the VHOST_USER_SET_DEV_INFO message. > > Signed-off-by: Wei Wang > > --- > docs/specs/vhost-user.txt | 21 ++++++++++++++++----- > 1 file changed, 16 insertions(+), 5 deletions(-) > > diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt > index fdc99ea..da1314d 100644 > --- a/docs/specs/vhost-user.txt > +++ b/docs/specs/vhost-user.txt > @@ -264,11 +264,12 @@ restarted. > Protocol features > ----------------- > > -#define VHOST_USER_PROTOCOL_F_MQ 0 > -#define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1 > -#define VHOST_USER_PROTOCOL_F_RARP 2 > -#define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 > -#define VHOST_USER_PROTOCOL_F_VHOST_PCI 4 > +#define VHOST_USER_PROTOCOL_F_MQ 0 > +#define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1 > +#define VHOST_USER_PROTOCOL_F_RARP 2 > +#define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 > +#define VHOST_USER_PROTOCOL_F_VHOST_PCI 4 > +#define VHOST_USER_PROTOCOL_F_VERSATILE_SLAVE 5 > > > I would rather name it after the message, > VHOST_USER_PROTOCOL_F_SET_DEV_INFO OK, I will take this suggestion. Thanks. <*v2-AR1*> > > > Message types > ------------- > @@ -514,6 +515,16 @@ Message types > #define VHOST_USER_SET_PEER_CONNECTION_F_CREATE 2 > #define VHOST_USER_SET_PEER_CONNECTION_F_DESTROY 3 > > + * VHOST_USER_SET_DEV_INFO > + > + Id: 21 > + Equivalent ioctl: N/A > + Master payload: u64 > > + > + The master sends the device type info to the slave. > > > What is the meaning of this payload? Is it the virtio device id? > better be explicit about it. > > If it is the case, I would name the message "VHOST_USER_SET_DEVICE_ID". Yes, currently we only have the virtio device id as the payload. I was thinking that in the future we would have other more info about the device. But no problem, I will change to use "VHOST_USER_SET_DEVICE_ID" for now. <*v2-AR2*> Best, Wei