Re: [dpdk-dev] [PATCH v5] vfio: fix workaround of BAR mapping

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Thu, 26 Jul 2018 11:35:43 +0200
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Takeshi Yoshimura <t.yoshimura8869@gmail.com>
> Cc: dev@dpdk.org, Anatoly Burakov <anatoly.burakov@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v5] vfio: fix workaround of BAR mapping
> 
> 
> 20/07/2018 10:13, Takeshi Yoshimura:
> > Currently, VFIO will try to map around MSI-X table in the BARs. When
> > MSI-X table (page-aligned) size is equal to (page-aligned) size of BAR,
> > VFIO will just skip the BAR.
> >
> > Recent kernel versions will allow VFIO to map the entire BAR containing
> > MSI-X tables (*), so instead of trying to map around the MSI-X vector
> > or skipping the BAR entirely if it's not possible, we can now try
> > mapping the entire BAR first. If mapping the entire BAR doesn't
> > succeed, fall back to the old behavior of mapping around MSI-X table or
> > skipping the BAR.
> >
> > (*): "vfio-pci: Allow mapping MSIX BAR",
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> > commit/?id=a32295c612c57990d17fb0f41e7134394b2f35f6
> >
> > Fixes: 90a1633b2347 ("eal/linux: allow to map BARs with MSI-X tables")
> >
> > Signed-off-by: Takeshi Yoshimura <t.yoshimura8869@gmail.com>
> > Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>


This change set breaks thunderx/octeontx platform with following error.(Tested with 4.9.0 kernel)

EAL:   probe driver: 177d:a034 net_thunderx
EAL:   using IOMMU type 1 (Type 1)
EAL: pci_map_resource(): cannot mmap(44, 0xffff60200000, 0x200000, 0x40000000000): Invalid argument (0xffffffffffffffff)
EAL: PCI device 0001:01:00.2 on NUMA socket 0
EAL:   probe driver: 177d:a034 net_thunderx
EAL: pci_map_resource(): cannot mmap(47, 0xffff60600000, 0x200000, 0x40000000000): Invalid argument (0xffffffffffffffff)

According Linux kernel change, user space application suppose to use VFIO_REGION_INFO_CAP_MSIX_MAPPABLE
capability to detect this feature to work < 4.15 kernel. Right? if so, Why we
are doing this retry based logic?





> 
> Applied, thanks
> 
> 
>