From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8DC57A09FF; Tue, 5 Jan 2021 10:32:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 22C641607A4; Tue, 5 Jan 2021 10:32:53 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id C7544160744 for ; Tue, 5 Jan 2021 10:32:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609839171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yuPpQ3UUNVR8ihPGWmvM0+bIvG8Q/AlLSz4lsF9HvbA=; b=e5A7V1jedlWVvxGyxv7bi7WxqUKk/5Hg6eNkkgUTsBuAcp/nbChvumUBSLWloTEmt6u+L1 s+7op5j+NPnum4GW5TOXZVUcJT/J+AMn2Hly1d0pVs10DaqhdfjmUB7pcY8Mm3Mw/SdPfU PMricvmhjDjK0B5C0uRrZna3ouuTXro= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-165-h53fsC4zOJihvbrE50qiIg-1; Tue, 05 Jan 2021 04:32:49 -0500 X-MC-Unique: h53fsC4zOJihvbrE50qiIg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 11C98107ACE6; Tue, 5 Jan 2021 09:32:48 +0000 (UTC) Received: from [10.36.110.9] (unknown [10.36.110.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9160B61F55; Tue, 5 Jan 2021 09:32:46 +0000 (UTC) To: Xueming Li , Chenbo Xia Cc: dev@dpdk.org, Matan Azrad , Asaf Penso References: <1603697101-8947-1-git-send-email-xuemingl@nvidia.com> From: Maxime Coquelin Message-ID: <8bb153e9-ead3-19c6-e0aa-c378fa85520f@redhat.com> Date: Tue, 5 Jan 2021 10:32:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1603697101-8947-1-git-send-email-xuemingl@nvidia.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC] vhost: support raising device error X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Xueming, On 10/26/20 8:25 AM, Xueming Li wrote: > According to virtio spec, The device SHOULD set DEVICE_NEEDS_RESET when > it enters an error state that a reset is needed. If DRIVER_OK is set, > after it sets DEVICE_NEEDS_RESET, the device MUST send a device > configuration change notification to the driver. > > This patch introduces new api to raise vDPA hardware error and escalates > configuration change to vhost via client message > VHOST_USER_SLAVE_CONFIG_CHANGE_MSG. > > The vhost should check DRIVER_OK and decide whether to notify driver. > > Signed-off-by: Xueming Li > --- > lib/librte_vhost/rte_vdpa_dev.h | 12 ++++++++++++ > lib/librte_vhost/version.map | 1 + > lib/librte_vhost/vhost_user.c | 14 ++++++++++++++ > 3 files changed, 27 insertions(+) > > diff --git a/lib/librte_vhost/rte_vdpa_dev.h b/lib/librte_vhost/rte_vdpa_dev.h > index a60183f780..87b7397c6f 100644 > --- a/lib/librte_vhost/rte_vdpa_dev.h > +++ b/lib/librte_vhost/rte_vdpa_dev.h > @@ -117,6 +117,18 @@ rte_vdpa_unregister_device(struct rte_vdpa_device *dev); > int > rte_vhost_host_notifier_ctrl(int vid, uint16_t qid, bool enable); > > +/** > + * Set device hardware error and notify host. > + * > + * @param vid > + * vhost device id > + * @return > + * 0 on success, -1 on failure > + */ > +__rte_experimental > +int > +rte_vhost_host_raise_error(int vid); > + > /** > * Synchronize the used ring from mediated ring to guest, log dirty > * page for each writeable buffer, caller should handle the used > diff --git a/lib/librte_vhost/version.map b/lib/librte_vhost/version.map > index 9183d6f2fc..5a4c5dc818 100644 > --- a/lib/librte_vhost/version.map > +++ b/lib/librte_vhost/version.map > @@ -76,4 +76,5 @@ EXPERIMENTAL { > rte_vhost_async_channel_unregister; > rte_vhost_submit_enqueue_burst; > rte_vhost_poll_enqueue_completed; > + rte_vhost_host_raise_error; > }; > diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c > index d20c8c57ad..d8353176f2 100644 > --- a/lib/librte_vhost/vhost_user.c > +++ b/lib/librte_vhost/vhost_user.c > @@ -2992,6 +2992,20 @@ rte_vhost_slave_config_change(int vid, bool need_reply) > return vhost_user_slave_config_change(dev, need_reply); > } > > +int > +rte_vhost_host_raise_error(int vid) > +{ > + struct virtio_net *dev; > + > + dev = get_device(vid); > + if (!dev) > + return -ENODEV; > + > + dev->status |= VIRTIO_DEVICE_STATUS_DEV_NEED_RESET; > + > + return vhost_user_slave_config_change(dev, 0); In order to be able to send VHOST_USER_SLAVE_CONFIG_CHANGE_MSG request, we need to negotiate the VHOST_USER_PROTOCOL_F_CONFIG feature, and ensure it is supported by the master. From the Vhost-user spec in Qemu: " ``VHOST_USER_SLAVE_CONFIG_CHANGE_MSG`` :id: 2 :equivalent ioctl: N/A :slave payload: N/A :master payload: N/A When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, vhost-user slave sends such messages to notify that the virtio device's configuration space has changed, for those host devices which can support such feature, host driver can send ``VHOST_USER_GET_CONFIG`` message to slave to get the latest content. If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and slave set the ``VHOST_USER_NEED_REPLY`` flag, master must respond with zero when operation is successfully completed, or non-zero otherwise. " Also, it is not clear in the spec that it should be sent on status updates. Finally, if we go and advertise we support VHOST_USER_PROTOCOL_F_CONFIG, we will have to support VHOST_USER_GET_CONFIG and VHOST_USER_SET_CONFIG request handling in the backend. I think it might be interesting to support it in the case of vDPA, but full support needs to be added otherwise it will break. Thanks, Maxime > +} > + > static int vhost_user_slave_set_vring_host_notifier(struct virtio_net *dev, > int index, int fd, > uint64_t offset, >