From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id ADD312BBE for ; Mon, 11 Jul 2016 11:50:27 +0200 (CEST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OA500LXQA01DL60@mailout1.w1.samsung.com> for dev@dpdk.org; Mon, 11 Jul 2016 10:50:25 +0100 (BST) X-AuditID: cbfec7f5-f792a6d000001302-73-57836be1c960 Received: from eusync3.samsung.com ( [203.254.199.213]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 75.C5.04866.1EB63875; Mon, 11 Jul 2016 10:50:25 +0100 (BST) Received: from [106.109.129.180] by eusync3.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0OA500J92A00CU80@eusync3.samsung.com>; Mon, 11 Jul 2016 10:50:25 +0100 (BST) To: Yuanhan Liu References: <1463748604-27251-1-git-send-email-i.maximets@samsung.com> <20160701073506.GQ2831@yliu-dev.sh.intel.com> <577CE930.2070007@samsung.com> <20160706122446.GO26521@yliu-dev.sh.intel.com> <577F9328.1030901@samsung.com> <20160710131731.GS26521@yliu-dev.sh.intel.com> <20160711083825.GY26521@yliu-dev.sh.intel.com> Cc: dev@dpdk.org, Huawei Xie , Dyasly Sergey , Heetae Ahn , Jianfeng Tan From: Ilya Maximets Message-id: <57836BE0.2070401@samsung.com> Date: Mon, 11 Jul 2016 12:50:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-version: 1.0 In-reply-to: <20160711083825.GY26521@yliu-dev.sh.intel.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsVy+t/xq7oPs5vDDc78F7V492k7k8W0z7fZ LdpnnmWyuNL+k92ie/YXNovJs6Usrk+4wOrA7vFrwVJWj8V7XjJ5zDsZ6NG3ZRVjAEsUl01K ak5mWWqRvl0CV8afXY+YChYIVcz/8petgXEDXxcjJ4eEgInEpt+r2CBsMYkL99YD2VwcQgJL GSWWPNgN5bxglOifNpEVpEpYwE9i7YZJjCC2iICuxNM561ghio4zSezo7QZzmAVWM0rcfb2K BaSKTUBH4tTqI0AdHBy8AloSNz4Ig4RZBFQlpu1cxQ5iiwpESMza/oMJxOYVEJT4MfkeWCun gLXE1DsbWUFamQX0JO5f1AIJMwvIS2xe85Z5AqPALCQdsxCqZiGpWsDIvIpRNLU0uaA4KT3X SK84Mbe4NC9dLzk/dxMjJLC/7mBceszqEKMAB6MSD2/A9qZwIdbEsuLK3EOMEhzMSiK8y9Ka w4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzztz1PkRIID2xJDU7NbUgtQgmy8TBKdXAuCB3l6X3 swu+/Z/jzr4otYlc7OPzpedec2Da/DdTF1k//nZJsqBy7c5ZylvU7f6dtP4ee+fny3zt8nIW oYXu5z7Mrd6YpLVb1Xe2qMaHixvajoTUbNXZs3VNYE39dcH4dId1W0IV3fv/3oi4XtV/lDfn cMjjKRPqtDUP7XO+sOUt6ySvF3ZXMpRYijMSDbWYi4oTAYcOA3poAgAA Subject: Re: [dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 09:50:27 -0000 On 11.07.2016 11:38, Yuanhan Liu wrote: > On Sun, Jul 10, 2016 at 09:17:31PM +0800, Yuanhan Liu wrote: >> On Fri, Jul 08, 2016 at 02:48:56PM +0300, Ilya Maximets wrote: >>> >>> Another point is that crash constantly happens on queue_id=3 (second RX queue) in >>> my scenario. It is newly allocated virtqueue while reconfiguration from rxq=1 to >>> rxq=2. >> >> That's a valuable message: what's your DPDK HEAD commit while triggering >> this issue? fbfd99551ca3 ("mbuf: add raw allocation function") > > I guess I have understood what goes wrong in you case. > > I would guess that your vhost has 2 queues (here I mean queue-pairs, > including one Tx and Rx queue; below usage is the same) configured, > so does to your QEMU. However, you just enabled 1 queue while starting > testpmd inside the guest, and you want to enable 2 queues by running > following testpmd commands: > > stop > port stop all > port config all rxq 2 > port config all txq 2 > port start all > > Badly, that won't work for current virtio PMD implementation, and what's > worse, it triggers a vhost crash, the one you saw. > > Here is how it comes. Since you just enabled 1 queue while starting > testpmd, it will setup 1 queue only, meaning only one queue's **valid** > information will be sent to vhost. You might see SET_VRING_ADDR > (and related vhost messages) for the other queue as well, but they > are just the dummy messages: they don't include any valid/real > information about the 2nd queue: the driver don't setup it after all. > > So far, so good. It became broken when you run above commands. Those > commands do setup for the 2nd queue, however, they failed to trigger > the QEMU virtio device to start the vhost-user negotiation, meaning > no SET_VRING_ADDR will be sent for the 2nd queue, leaving vhost > untold and not updated. > > What's worse, above commands trigger the QEMU to send SET_VRING_ENABLE > messages, to enable all the vrings. And since the vrings for the 2nd > queue are not properly configured, the crash happens. Hmm, why 2nd queue works properly with my fix to vhost in this case? > So maybe we should do virtio reset on port start? I guess it was removed by this patch: a85786dc816f ("virtio: fix states handling during initialization").