From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1E84AA0A02; Thu, 13 May 2021 16:12:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8B42A4067E; Thu, 13 May 2021 16:12:00 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 736BF4003F for ; Thu, 13 May 2021 16:11:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620915117; 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: in-reply-to:in-reply-to:references:references; bh=6sscxTUt+fEzRBgO2BljpVkVlof0GOATqbwI6XMv8QI=; b=UZ1aMYeO4Fd7GHViFNMwcdsOZ2amWSUCC2qYWO+ktsGeZzmd4wRkC4zpP21vs6ZuFu76KB jyatez22tnYX+KxynIqt0O8oKQirsBGPJl0AxEOJi2TXmdd1OjijBnRyNwO99x7fokGQMZ QAfrDICl+MTAuFoKiHqUjUdqTC8hZ9U= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-434-H6cY5YbKMFe_SEHpxVRoTg-1; Thu, 13 May 2021 10:11:56 -0400 X-MC-Unique: H6cY5YbKMFe_SEHpxVRoTg-1 Received: by mail-vs1-f69.google.com with SMTP id i16-20020a67c2100000b0290227fd428db0so12031055vsj.10 for ; Thu, 13 May 2021 07:11:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6sscxTUt+fEzRBgO2BljpVkVlof0GOATqbwI6XMv8QI=; b=f6+DC6IH1I02J1lChVei7lroWIPnoKeSx+alUCZhDjpknSN1qX2FFKbI33k8OcBXon LvITv8/yQE32nFB7OsCx6zgXwCltGu4+CVGM2g5PYmbjuXwIFX2QYCjUekjPVD+eqry5 28y2rQYkWpGy0rxAC8QyBgFbrXzildTDLeFWa3pGq7qjlnMS0agZ2Uxp/z4lP9bt2w5o YHUQdyM1WiRC0LhoOjy8HNs6OnaLejcCGesnUEetLQ96e9xBZPPFydvyPt89fJUguJkB GyuxskHheKZRX5iLfRAmAtyA830I5pAFjIe4n8vK13MjnrCPdX75tpgmWo2i2QtCdq4L swEA== X-Gm-Message-State: AOAM533M6mIXjn2aCopHnFHvY5ScahvC1XmYnEqyoXVCSko4icMP/Y5t FYATSJv3+/2f+uchjxSbXpV2K5xcJ+L8pAfq2Yq5+Q8kAi0+DGVnudjO95rQm2VzEOq/PE9Qi4a on8vOQz8/pc1YmstDo0g= X-Received: by 2002:ab0:132a:: with SMTP id g39mr7513992uae.53.1620915115652; Thu, 13 May 2021 07:11:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEno3dYpF2Mm/2Qm/iUjL1FxgRD5Bi2skDaH8EkACq25ygEWe9/y1aN7HZ7w84Mk7Ou/bOI0JcRtH7UXirD+E= X-Received: by 2002:ab0:132a:: with SMTP id g39mr7513942uae.53.1620915115338; Thu, 13 May 2021 07:11:55 -0700 (PDT) MIME-Version: 1.0 References: <20210513122826.49910-1-chenbo.xia@intel.com> In-Reply-To: <20210513122826.49910-1-chenbo.xia@intel.com> From: David Marchand Date: Thu, 13 May 2021 16:11:43 +0200 Message-ID: To: Chenbo Xia , Maxime Coquelin Cc: dev , Kevin Traynor , Pei Zhang , "Yigit, Ferruh" , Thomas Monjalon Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] vhost: fix wrong IOTLB initialization 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" On Thu, May 13, 2021 at 2:38 PM Chenbo Xia wrote: > > This patch fixes an issue of application crash because of vhost iotlb > not initialized when virtio has multiqueue enabled. > > iotlb messages will be sent when some queues are not enabled. If we > initialize iotlb in vhost_user_set_vring_num, it could happen that > iotlb update comes when iotlb pool of disabled queues are not > initialized. This makes the problem I reproduced disappear at init, but I noticed the segfault after restarting testpmd once. And a little bit after this, my vm crashed. This is not systematic, so I guess there is some condition with how the virtio device is initialised in the vm. One question below. Bugzilla ID: 703 > Fixes: 968bbc7e2e50 ("vhost: avoid IOTLB mempool allocation while IOMMU disabled") > Reported-by: Pei Zhang > Signed-off-by: Chenbo Xia > --- > lib/vhost/vhost_user.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c > index 611ff209e3..ae4df8eb69 100644 > --- a/lib/vhost/vhost_user.c > +++ b/lib/vhost/vhost_user.c > @@ -311,6 +311,7 @@ vhost_user_set_features(struct virtio_net **pdev, struct VhostUserMsg *msg, > uint64_t features = msg->payload.u64; > uint64_t vhost_features = 0; > struct rte_vdpa_device *vdpa_dev; > + uint32_t i; > > if (validate_msg_fds(msg, 0) != 0) > return RTE_VHOST_MSG_RESULT_ERR; > @@ -389,6 +390,14 @@ vhost_user_set_features(struct virtio_net **pdev, struct VhostUserMsg *msg, > vdpa_dev->ops->set_features(dev->vid); > > dev->flags &= ~VIRTIO_DEV_FEATURES_FAILED; > + > + if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM)) { > + for (i = 0; i < dev->nr_vring; i++) { I don't know the vhost-user protocol. At this point of the device init/life, are we sure nr_vring is set to the max number of vring? The logs I have tend to say it is the case, but is there a guarantee in the protocol? Another way to fix would be to allocate on the first VHOST_USER_IOTLB_MSG message received for a vring. > + if (vhost_user_iotlb_init(dev, i)) > + return RTE_VHOST_MSG_RESULT_ERR; > + } > + } > + > return RTE_VHOST_MSG_RESULT_OK; > } > -- David Marchand