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 B9F3BA0C45; Fri, 24 Sep 2021 10:21:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 38AC94122D; Fri, 24 Sep 2021 10:21:40 +0200 (CEST) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by mails.dpdk.org (Postfix) with ESMTP id 0D71540142 for ; Fri, 24 Sep 2021 10:21:39 +0200 (CEST) Received: by mail-wr1-f45.google.com with SMTP id i24so8880211wrc.9 for ; Fri, 24 Sep 2021 01:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=a38IPQ3IUdtTuEpJcZrsXFEAs2pfYeDNqsvI4lMb8HE=; b=enRQKUzK1yX/R3V1vMezHfle4JZxrH9SdKdh2ta74zlhX0lrrzVOxM/Rw7KXjLRjS2 PCS3vHATyfl+YxUzpTkqbTK8tPxUJUGIA7PMa0wcFskgf08mLbaLPGvQqAO8CvTzVmaT Fe+JPdpGpNBbYIwa0ZeRytrxpc4X3u/Q1PGTc4LTWZ1pZuOTM9uZtx/wCgqulI3QpIJE D2j++xhL5RJCIQQ/GNHcwLBSfbdKSqUE0NrCUcRQxjRAfaLAjaIM0jXokPUpPdGUyMpl FmyB3XYMZblldTvX3hcw+GZDFzlYD9SH+q78KmdOhZV9+3dMjJJaLfRp1S1y14X3mQg3 ENUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=a38IPQ3IUdtTuEpJcZrsXFEAs2pfYeDNqsvI4lMb8HE=; b=Vag+nGATXpku2g/OdEsmNtrMLkD2/AEQ477J8RHYX3oQpZtPHf9RMDsTKs8726+OmC CYjq7nrzdu1qzmNfZUE7vhzTU7rDLJF7bORjqh0KtAuROMrXIBY/dWQVVBBg9tFO7ddm Td1P+kQPWCCexrqhS3diSdx49cGj+9pO4x9kxlr75Q/DaFuWfogJWInLnc/9MdPMzNft ZXPGSCpb3EhizDuepKQO9JWTqWZlDwYLQI7gpv0YlT0exs6Zo1XQSiTM6TqIgkZZ1J6K hs1TF1s5JfopcnYZR5ufrdgFiGoWZLgck5fxpkC//25BmdKz92OHJ4KzQ2gb2xgjvVmJ eWlA== X-Gm-Message-State: AOAM532mHYmjZFTdXQAvQRU0LcIfQcuvOi7WoOn65FoWzMPu3uJcCmdV l24eP4uYvIVftKMC3Szc1JlCUbxW+Ry1fg== X-Google-Smtp-Source: ABdhPJyk5s9Q3utYZ+oGp0XlufYdpMcWvYB5biP4XUCkir8DGuOhptUsGwCMUwMqIfIjwGN2vCsFLw== X-Received: by 2002:adf:f949:: with SMTP id q9mr508638wrr.331.1632471698795; Fri, 24 Sep 2021 01:21:38 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id d3sm8889250wrb.36.2021.09.24.01.21.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Sep 2021 01:21:38 -0700 (PDT) Date: Fri, 24 Sep 2021 10:21:37 +0200 From: Olivier Matz To: dev@dpdk.org, Maxime Coquelin , Chenbo Xia Cc: David Marchand Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dpdk-dev] cannot use virtio-user pmd in IOVA=PA mode anymore 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" Hello, I recently tested a use-case with our application using the main branch of dpdk.org. - the application runs inside a standard x86 VM (no IOMMU) - there are emulated physical NICs inside the VM - we use virtio-user pmds connected to tap interfaces through the vhost-net backend for exception path This use-case works with the the stable 20.11 branch, but not with the current main dpdk.org branch. The virtio-user driver refuses to start in IOVA=PA mode: vdev_probe_all_drivers(): virtio_user0 requires VA IOVA mode but current mode is PA, not initializing EAL: Driver cannot attach the device (virtio_user0) This is likely due to these commits: 8d935fff5546 ("bus/vdev: add driver IOVA VA mode requirement") 17043a2909bb ("net/virtio: force IOVA as VA mode for virtio-user") We didn't see this problem before because we are only testing dpdk.org main branch on physical machines that have an IOMMU. I'm not sure to understand the reasons for which the ability to run a virtio-user pmd in IOVA=PA mode was removed. The commitlog of 17043a2909bb says: At least Vhost-user backend of Virtio-user PMD requires IOVA as VA mode. Until now, it was implemented as a hack by forcing to use mbuf's buf_addr field instead of buf_iova. I don't get why vhost-user backend would require IOVA=VA. Note that we also have a use-case where a virtio-user pmd is connected to our pmd-vhost in another application, which was working with 20.11. If there is a constraint with vhost-user backend, what about vhost-net backend? Would it make sense to re-allow this feature by somehow reverting 17043a2909bb with some additional cleanup? I am aware that a solution can be to configure qemu to enable a vIOMMU, but it is not my preferred solution yet, as it would impact our users that do not do this currently. Thanks! Olivier