DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Eelco Chaudron <echaudro@redhat.com>,
	Alejandro Lucero <alejandro.lucero@netronome.com>
Cc: dev@dpdk.org, stable@dpdk.org
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v4 2/5] bus/pci: use IOVAs check when setting IOVA mode
Date: Wed, 11 Jul 2018 11:41:48 +0100	[thread overview]
Message-ID: <ffefea2a-1fab-f915-2f73-c9da3c249d9d@intel.com> (raw)
In-Reply-To: <A36D1731-8E03-424B-8D72-FE765B38A5E5@redhat.com>

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 <alejandro.lucero@netronome.com>
>> ---
>>  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 <rte_devargs.h>
>>  #include <rte_memcpy.h>
>>  #include <rte_vfio.h>
>> +#include <rte_memory.h>
>>
>>  #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

  reply	other threads:[~2018-07-11 10:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-10 17:25 [dpdk-dev] [PATCH v4 0/5] use IOVAs check based on DMA mask Alejandro Lucero
2018-07-10 17:25 ` [dpdk-dev] [PATCH v4 1/5] mem: add function for checking memsegs IOVAs addresses Alejandro Lucero
2018-07-11 10:12   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-07-10 17:25 ` [dpdk-dev] [PATCH v4 2/5] bus/pci: use IOVAs check when setting IOVA mode Alejandro Lucero
2018-07-11 10:18   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-07-11 10:41     ` Burakov, Anatoly [this message]
2018-07-10 17:25 ` [dpdk-dev] [PATCH v4 3/5] mem: use address hint for mapping hugepages Alejandro Lucero
2018-07-10 17:25 ` [dpdk-dev] [PATCH v4 4/5] net/nfp: check hugepages IOVAs based on DMA mask Alejandro Lucero
2018-07-10 17:25 ` [dpdk-dev] [PATCH v4 5/5] net/nfp: support IOVA VA mode Alejandro Lucero
2018-07-26 15:41 ` [dpdk-dev] [PATCH v4 0/5] use IOVAs check based on DMA mask Thomas Monjalon
2018-07-27  7:03   ` Alejandro Lucero
2018-07-27  8:01     ` Thomas Monjalon
2018-07-27  8:22       ` Alejandro Lucero
2018-07-27  8:52         ` Thomas Monjalon
2018-07-27  8:59           ` Alejandro Lucero
2018-07-27  8:54         ` Burakov, Anatoly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ffefea2a-1fab-f915-2f73-c9da3c249d9d@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=dev@dpdk.org \
    --cc=echaudro@redhat.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).