From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 8AA711B51A; Wed, 11 Jul 2018 12:41:55 +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 orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2018 03:41:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,338,1526367600"; d="scan'208";a="71398842" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.102]) ([10.237.220.102]) by fmsmga001.fm.intel.com with ESMTP; 11 Jul 2018 03:41:52 -0700 To: Eelco Chaudron , Alejandro Lucero Cc: dev@dpdk.org, stable@dpdk.org References: <1531243552-7795-1-git-send-email-alejandro.lucero@netronome.com> <1531243552-7795-3-git-send-email-alejandro.lucero@netronome.com> From: "Burakov, Anatoly" Message-ID: Date: Wed, 11 Jul 2018 11:41:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v4 2/5] bus/pci: use IOVAs check when setting IOVA mode 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: Wed, 11 Jul 2018 10:41:56 -0000 On 11-Jul-18 11:18 AM, Eelco Chaudron wrote: > > > On 10 Jul 2018, at 19:25, Alejandro Lucero wrote: > >> Although VT-d emulation currently only supports 39 bits, it could >> be iovas being within that supported range. This patch allows >> IOVA mode in such a case. >> >> Indeed, memory initialization code can be modified for using lower >> virtual addresses than those used by the kernel for 64 bits processes >> by default, and therefore memsegs iovas can use 39 bits or less for >> most system. And this is likely 100% true for VMs. >> >> Applicable to v17.11.3 only. >> >> Signed-off-by: Alejandro Lucero >> --- >>  drivers/bus/pci/linux/pci.c | 15 +++++++++++---- >>  1 file changed, 11 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c >> index 74deef3..792c819 100644 >> --- a/drivers/bus/pci/linux/pci.c >> +++ b/drivers/bus/pci/linux/pci.c >> @@ -43,6 +43,7 @@ >>  #include >>  #include >>  #include >> +#include >> >>  #include "eal_private.h" >>  #include "eal_filesystem.h" >> @@ -613,10 +614,12 @@ >>      fclose(fp); >> >>      mgaw = ((vtd_cap_reg & VTD_CAP_MGAW_MASK) >> VTD_CAP_MGAW_SHIFT) >> + 1; >> -    if (mgaw < X86_VA_WIDTH) >> + >> +    if (!rte_eal_check_dma_mask(mgaw)) >> +        return true; >> +    else >>          return false; >> >> -    return true; >>  } >>  #elif defined(RTE_ARCH_PPC_64) >>  static bool >> @@ -640,13 +643,17 @@ >>  { >>      struct rte_pci_device *dev = NULL; >>      struct rte_pci_driver *drv = NULL; >> +    int iommu_dma_mask_check_done = 0; >> >>      FOREACH_DRIVER_ON_PCIBUS(drv) { >>          FOREACH_DEVICE_ON_PCIBUS(dev) { >>              if (!rte_pci_match(drv, dev)) >>                  continue; >> -            if (!pci_one_device_iommu_support_va(dev)) >> -                return false; >> +            if (!iommu_dma_mask_check_done) { >> +                if (pci_one_device_iommu_support_va(dev) < 0) >> +                    return false; >> +                iommu_dma_mask_check_done  = 1; > > As I do not know enough on what IOMMU hardware can coexist, I leave this > patch for others to review. > Here is the previous question/answer: > >>>> Not sure why this change? Why do we only need to check one device on >>>> all the buses? > >>> Because there is just one emulated IOMMU hardware. The limitation in >>> this case is not in a specific PCI device. And I do not think it is >>> possible to have two different (emulated or not) IOMMU hardware. Yes, >>> you can have more than one controller but being same IOMMU type. > > If the above is confirmed, you can consider this patch ack’ed. As far as my knowledge goes, the above is correct. There can't be more than one IOMMU type per platform, and limitations specific for IOMMU controller apply to all devices, not just one. I'm not sure if it's possible to have two IOMMU controllers of the same type with different address width, but i think even if it is possible, we can safely consider this to be unlikely :) > >> +            } >>          } >>      } >>      return true; >> -- >> 1.9.1 > -- Thanks, Anatoly