From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 164BA235; Mon, 18 Jun 2018 18:12:35 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2018 09:12:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,240,1526367600"; d="scan'208";a="65109076" Received: from kraken.imu.intel.com (HELO Sent) ([10.217.246.153]) by fmsmga001.fm.intel.com with SMTP; 18 Jun 2018 09:12:32 -0700 Received: by Sent (sSMTP sendmail emulation); Mon, 18 Jun 2018 21:53:10 +0200 From: Dariusz Stojaczyk To: dev@dpdk.org, Anatoly Burakov Cc: Dariusz Stojaczyk , stable@dpdk.org Date: Mon, 18 Jun 2018 21:53:09 +0200 Message-Id: <1529351589-173939-1-git-send-email-dariuszx.stojaczyk@intel.com> X-Mailer: git-send-email 2.7.4 Subject: [dpdk-dev] [PATCH] memory: do not use base-virtaddr in secondary processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:12:36 -0000 Since secondary process' address space is highly dictated by the primary process' mappings, it doesn't make much sense to use base-virtaddr for secondary processes. This patch is intended to fix PCI resource mapping in secondary processes using the same base-virtaddr as their primary processes. PCI uses the end of the hugepage memory area to map all resources. [pci_find_max_end_va()] It works for primary processes, but can't be mapped 1:1 by secondary ones, as the same addresses are currently always occupied by shadow memseg lists, which were created with eal_get_virtual_area(NULL, ...). ``` PRIMARY PROCESS 0x6e00e00000 388K rw-s- fbarray_memseg-2048k-1-3 0x6e01000000 16777216K r---- [ anon ] 0x7201000000 16K rw-s- resource0 SECONDARY PROCESS 0x6e00e00000 388K rw-s- fbarray_memseg-2048k-1-3 0x6e01000000 16777216K r---- [ anon ] 0x7201000000 4K rw-s- fbarray_memseg-1048576k-0-0_203213 ``` Fixes: 524e43c2ad9a ("mem: prepare memseg lists for multiprocess sync") Cc: anatoly.burakov@intel.com Cc: stable@dpdk.org Signed-off-by: Dariusz Stojaczyk --- lib/librte_eal/common/eal_common_memory.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c index 53d9b51..6c47e11 100644 --- a/lib/librte_eal/common/eal_common_memory.c +++ b/lib/librte_eal/common/eal_common_memory.c @@ -56,7 +56,8 @@ eal_get_virtual_area(void *requested_addr, size_t *size, allow_shrink = (flags & EAL_VIRTUAL_AREA_ALLOW_SHRINK) > 0; unmap = (flags & EAL_VIRTUAL_AREA_UNMAP) > 0; - if (next_baseaddr == NULL && internal_config.base_virtaddr != 0) + if (next_baseaddr == NULL && internal_config.base_virtaddr != 0 && + rte_eal_process_type() == RTE_PROC_PRIMARY) next_baseaddr = (void *) internal_config.base_virtaddr; if (requested_addr == NULL && next_baseaddr) { -- 2.7.4