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 7D3FCA052A; Wed, 27 Jan 2021 17:45:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 66232140F88; Wed, 27 Jan 2021 17:45:37 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 1549B140F72 for ; Wed, 27 Jan 2021 17:45:34 +0100 (CET) IronPort-SDR: P6+UFtAxLfTesL8VbuKCih4NLjDj12oKikPUejbgYMESAzFuS2FZrEH440eH9mbMG7LTanGbQQ oC3pum8QQuWQ== X-IronPort-AV: E=McAfee;i="6000,8403,9877"; a="159269464" X-IronPort-AV: E=Sophos;i="5.79,380,1602572400"; d="scan'208";a="159269464" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2021 08:45:31 -0800 IronPort-SDR: sGh6FJ3vXdAAx/YS3UEunojbkDgkF0u3CSkR1guFOrqaXmlGBmxUcaz8O/B1Vo7u3+HdNL6JPG 8ybFz/i1ob5w== X-IronPort-AV: E=Sophos;i="5.79,380,1602572400"; d="scan'208";a="430161056" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.208.215]) ([10.213.208.215]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2021 08:45:29 -0800 To: =?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?= , Maxime Coquelin Cc: dev@dpdk.org, anatoly.burakov@intel.com, david.marchand@redhat.com, chenbo.xia@intel.com, grive@u256.net, "Xueming(Steven) Li" 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> <18871462-4d25-302a-2716-99ebec65c3ac@alibaba-inc.com> <40e0702d-7847-9dc3-1904-03a7b8e92c2e@alibaba-inc.com> <3c83a06d-c757-e470-441b-a8b7f496a953@redhat.com> <9b614cce-8e41-9ed6-a648-fbbe3fc14807@alibaba-inc.com> <71352868-a699-d876-25c3-b36df4f8649f@redhat.com> <22010641-89a9-15f5-6079-591cfef7dabb@intel.com> <915236c7-c8e1-b23c-d644-947fa22b3f26@alibaba-inc.com> From: Ferruh Yigit Message-ID: <21913480-a3d8-81d5-b493-c8d9657fc68f@intel.com> Date: Wed, 27 Jan 2021 16:45:27 +0000 MIME-Version: 1.0 In-Reply-To: <915236c7-c8e1-b23c-d644-947fa22b3f26@alibaba-inc.com> Content-Type: text/plain; charset=utf-8; format=flowed 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/27/2021 2:43 PM, 谢华伟(此时此刻） wrote: > > On 2021/1/27 18:32, Ferruh Yigit wrote: >> I was waiting for clarification if this can be solved in virtio, which seems >> clarified and decided to go with this patch, I am OK to proceed with patch 1 & 2. >> >> But first patch changes how PIO address get, it changes the Linux interface >> used to get the PIO. >> And as far as I can see second patch requires this new interface to be able to >> access the MEM resources. >> >> I have a concern that this interface change may cause issues with various >> distros, kernel versions etc.. And prefer it goes through a full -rc1 >> validation cycle. >> >> Huawei, I am aware the patch is around for a while but to play safe, I suggest >> considering it for early next release, so it can be tested enough, instead of >> getting if for -rc2/3 in this release. >> >> Thanks, >> ferruh >> > Hi Ferruh and Maxime: > > igb_uio kernel driver gets resource through pci_resource_start, i.e, > (dev)->resource[(bar)].start > > uio_pci_generic and the generic way in my patch 1 gets resource through the same > interface: > >         pci dev driver exports to userspace the bar resource attributes through > pci_dev->resource (check resource_show in kernel's drivers/pci/pci-sysfs.c) > > Other arch than x86 uses the same interface in their pci_uio_ioport_map. > > So patch 1 is the most generic way and shouldn't break things. /proc/ioports > should be fully dropped. > > Using /proc/ioport is partly my fault at the very beginning. It causes so much > mess. > > Could you please confirm this? > Hi Huawei, I confirm that interface is already in use, 'pci_parse_sysfs_resource()' does similar parsing. Most probably it is safe as you and Maxime said, and I am not trying to be difficult but extra conscious here. Will it cause too much trouble to consider the patch early next release? This gives more time and testing after the patch merged. Thanks, ferruh > Thanks huawei > >>> Could you please post v6? >>> >>> Thanks, >>> Maxime >>> >>>>> >>>>> It is not too late for this release, as the change will not be that >>>>> intrusive. But if you prepare such patch, please base it on top of my >>>>> virtio rework series; To make it easier to you, I added it to the dpdk- >>>>> next-virtio tree: >>>>> https://git.dpdk.org/next/dpdk-next-virtio/log/?h=virtio_pmd_rework_v2 >>>>> >>>>> Thanks, >>>>> Maxime >>>>> >>>>