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 93EB2A052A; Wed, 27 Jan 2021 11:40:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 301B4140CE8; Wed, 27 Jan 2021 11:40:25 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 501CA140CB8 for ; Wed, 27 Jan 2021 11:40:23 +0100 (CET) IronPort-SDR: eMBIUnJ/KOXKvfLFrboz+YYdj9YIouokQ72bSnVKtqFFy05hfqW9x0x+KXW1CUJGrDUQwR5d39 sdqkMvc7RjbA== X-IronPort-AV: E=McAfee;i="6000,8403,9876"; a="167723751" X-IronPort-AV: E=Sophos;i="5.79,379,1602572400"; d="scan'208";a="167723751" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2021 02:40:22 -0800 IronPort-SDR: oTjnvqwLQn3D7WlXRM4Rr4N4CfLMF9kj+172cwLw6a9OsGQuuLym4W46Z4QJo5ofmRVLdBv7Lw p0JYlseysrGQ== X-IronPort-AV: E=Sophos;i="5.79,379,1602572400"; d="scan'208";a="430054966" 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 02:40:20 -0800 To: =?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?= Cc: dev@dpdk.org, maxime.coquelin@redhat.com, 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-3-git-send-email-huawei.xhw@alibaba-inc.com> From: Ferruh Yigit Message-ID: <820d8f58-0a88-e9bc-e86e-6876f7f5f50f@intel.com> Date: Wed, 27 Jan 2021 10:40:16 +0000 MIME-Version: 1.0 In-Reply-To: <1603381885-88819-3-git-send-email-huawei.xhw@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 2/3] PCI: support MMIO in rte_pci_ioport_map/unap/read/write 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 10/22/2020 4:51 PM, 谢华伟(此时此刻） wrote: > From: "huawei.xhw" > > If IO BAR, we get PIO address. > If MMIO BAR, we get mapped virtual address. > We distinguish PIO and MMIO by their address like how kernel does. > ioread/write8/16/32 is provided to access PIO/MMIO. > BTW, for virtio on arch other than x86, BAR flag indicates PIO but is mapped. > > Signed-off-by: huawei.xhw <...> > @@ -408,15 +403,30 @@ > &end_addr, &flags) < 0) > goto error; > > - if (!(flags & IORESOURCE_IO)) { > - RTE_LOG(ERR, EAL, "%s(): bar resource other than IO is not supported\n", __func__); > + if (flags & IORESOURCE_IO) { > + iobar = 1; > + base = (unsigned long)phys_addr; > + RTE_LOG(INFO, EAL, "%s(): PIO BAR %08lx detected\n", __func__, base); > + } else if (flags & IORESOURCE_MEM) { > + iobar = 0; > + base = (unsigned long)dev->mem_resource[bar].addr; Hi Huawei, At this stage, to have a valid 'addr' it should be already mmap'ed, can you please provide the call stack when it is set/mmaped, to confirm it will be always valid at this point? Thanks, ferruh