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 431ADA04B5; Tue, 12 Jan 2021 17:58:34 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BF1AF140E8D; Tue, 12 Jan 2021 17:58:33 +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 1AAF1140E8B for ; Tue, 12 Jan 2021 17:58:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610470711; 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=mnftgJc65+NeFtVEo9U4VSJXSIktqvUQfwtWiwdn+RI=; b=ZlpZoW0yD/ErsuulUjqgXPMSSWWaxYT+RrLwQEW/sm4m1fRJ+LAuYSzf9ArXb2F5WENmoL vX6s3H5spHWomAwP+KC13lCTDWaf9lPOzRbufZ4en/Qeq0cmwD/fnOVdv/Dsvmg21Do4vK 1NUufOa/j9LAI4MIt6aDuhmNGeiYx/E= 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-107-X72NOlNdPCq04kv0Cw5f-A-1; Tue, 12 Jan 2021 11:58:27 -0500 X-MC-Unique: X72NOlNdPCq04kv0Cw5f-A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5E55D100C600; Tue, 12 Jan 2021 16:58:26 +0000 (UTC) Received: from [10.36.110.24] (unknown [10.36.110.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 60CAA1972B; Tue, 12 Jan 2021 16:58:21 +0000 (UTC) From: Maxime Coquelin To: =?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?= , ferruh.yigit@intel.com Cc: dev@dpdk.org, anatoly.burakov@intel.com, david.marchand@redhat.com, zhihong.wang@intel.com, chenbo.xia@intel.com, grive@u256.net References: <68ecd941-9c56-4de7-fae2-2ad15bdfd81a@alibaba-inc.com> <1603381885-88819-1-git-send-email-huawei.xhw@alibaba-inc.com> <1603381885-88819-4-git-send-email-huawei.xhw@alibaba-inc.com> Message-ID: Date: Tue, 12 Jan 2021 17:58:18 +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: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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] [PATCH v5 3/3] PCI: don't use vfio ioctl call to access PIO resource 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 1/12/21 10:37 AM, Maxime Coquelin wrote: > bus/pci: ... > > On 10/22/20 5:51 PM, 谢华伟(此时此刻） wrote: >> From: "huawei.xhw" >> >> VFIO should use the same way to map/read/write PORT IO as UIO, for >> virtio PMD. > > Please provide more details in the commit message on why the way VFIO > works today is wrong (The cover letter is lost once applied). > >> Signed-off-by: huawei.xhw > > Same comment about name format as on previous patches. > >> --- >> drivers/bus/pci/linux/pci.c | 8 ++++---- >> drivers/bus/pci/linux/pci_uio.c | 4 +++- >> 2 files changed, 7 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c >> index 0dc99e9..2ed9f2b 100644 >> --- a/drivers/bus/pci/linux/pci.c >> +++ b/drivers/bus/pci/linux/pci.c >> @@ -687,7 +687,7 @@ int rte_pci_write_config(const struct rte_pci_device *device, >> #ifdef VFIO_PRESENT >> case RTE_PCI_KDRV_VFIO: >> if (pci_vfio_is_enabled()) >> - ret = pci_vfio_ioport_map(dev, bar, p); >> + ret = pci_uio_ioport_map(dev, bar, p); > > Doesn't it create a regression with regards to needed capabilities? > My understanding is that before this patch we don't need to call iopl(), > whereas once applied it is required, correct? I did some testing today, and think it is not a regression with para- virtualized Virtio devices. Indeed, I thought it would be a regression with Legacy devices when IOMMU is enabled and the program is run as non-root (IOMMU enabled just to suport IOVA as VA mode). But it turns out para-virtualized Virtio legacy device and vIOMMU enabled is not a supported configuration by QEMU. Note that when noiommu mode is enabled, the app needs cap_sys_rawio, so same as iopl(). No regression in this case too. That said, with real (non para-virtualized) Virtio device using PIO like yours, doesn't your patch introduce a restriction for your device that it will require cap_sys_rawio whereas it would not be needed? Thanks, Maxime > Regards, > Maxime >