From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 5C5391B4A5; Tue, 9 Oct 2018 13:07:15 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 04:07:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,360,1534834800"; d="scan'208";a="86913538" Received: from btwcube1.sh.intel.com (HELO debian) ([10.67.104.158]) by FMSMGA003.fm.intel.com with ESMTP; 09 Oct 2018 04:03:23 -0700 Date: Tue, 9 Oct 2018 19:02:08 +0800 From: Tiwei Bie To: Maxime Coquelin Cc: dev@dpdk.org, zhihong.wang@intel.com, jfreimann@redhat.com, nicknickolaev@gmail.com, i.maximets@samsung.com, bruce.richardson@intel.com, alejandro.lucero@netronome.com, dgilbert@redhat.com, stable@dpdk.org Message-ID: <20181009110207.GA32180@debian> References: <20181008152557.14275-1-maxime.coquelin@redhat.com> <20181008152557.14275-5-maxime.coquelin@redhat.com> <20181009102125.GA27427@debian> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4 04/19] vhost: fix payload size of reply X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 11:07:16 -0000 On Tue, Oct 09, 2018 at 12:34:28PM +0200, Maxime Coquelin wrote: > On 10/09/2018 12:30 PM, Maxime Coquelin wrote: > > On 10/09/2018 12:21 PM, Tiwei Bie wrote: > > > On Mon, Oct 08, 2018 at 05:25:42PM +0200, Maxime Coquelin wrote: > > > > QEMU doesn't expect any payload for the reply of > > > > VHOST_USER_SET_LOG_BASE request, so don't send any. > > > > Note that the Vhost-user specification isn't clear about > > > > it and would need to be fixed. > > > > > > > > Fixes: 54f9e32305d4 ("vhost: handle dirty pages logging request") > > > > Cc: stable@dpdk.org > > > > > > > > Reported-by: Ilya Maximets > > > > Signed-off-by: Maxime Coquelin > > > > Acked-by: Ilya Maximets > > > > --- > > > >   lib/librte_vhost/vhost_user.c | 6 +++++- > > > >   1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/lib/librte_vhost/vhost_user.c > > > > b/lib/librte_vhost/vhost_user.c > > > > index 7f3e86778..71a0e7dd7 100644 > > > > --- a/lib/librte_vhost/vhost_user.c > > > > +++ b/lib/librte_vhost/vhost_user.c > > > > @@ -1296,7 +1296,11 @@ vhost_user_set_log_base(struct virtio_net > > > > **pdev, struct VhostUserMsg *msg) > > > >       dev->log_base = dev->log_addr + off; > > > >       dev->log_size = size; > > > > -    msg->size = sizeof(msg->payload.u64); > > > > +    /* > > > > +     * The spec is not clear about it (yet), but QEMU doesn't expect > > > > +     * any payload in the reply. > > > > +     */ > > > > +    msg->size = 0; > > > > > > I think the spec is clear about it that no payload is > > > expected in the reply: > > > > > > https://github.com/qemu/qemu/blob/7c69b7c84964/docs/interop/vhost-user.txt#L496 > > > > > It isn't really clear because there are two cases[0]: > > 1. VHOST_USER_PROTOCOL_F_LOG_SHMFD not negotiated: In this case no reply > >    has to be sent. > > 2. VHOST_USER_PROTOCOL_F_LOG_SHMFD negotiated: In this case reply with > >    empty payload hsa to be sent. > > > > [0]: https://github.com/qemu/qemu/blob/7c69b7c849641a39ba3defa40d384a2ba24cd7a2/docs/interop/vhost-user.txt#L177 > > > > And I would add that N/A isn't clear, because SET_VRING_ADDR specifies > N/A as slave payload, whereas the implementation does not implement a > reply. Good point. > > > > But below line in the spec needs to be fixed: > > > > > > https://github.com/qemu/qemu/blob/7c69b7c84964/docs/interop/vhost-user.txt#L495 > > > > > > > Indeed. > > > > > > > > >       return VH_RESULT_REPLY; > > > >   } > > > > -- > > > > 2.17.1 > > > >