bus/pci: pcidev access from secondary process

Message ID 1583452940-346826-1-git-send-email-vijay1054@gmail.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series bus/pci: pcidev access from secondary process |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/iol-intel-Performance success Performance Testing PASS
ci/Intel-compilation success Compilation OK
ci/iol-testing success Testing PASS
ci/travis-robot success Travis build: passed
ci/iol-mellanox-Performance success Performance Testing PASS

Commit Message

Vijaya Mohan Guvva March 6, 2020, 12:02 a.m. UTC
  For pci devices presented through igb_uio, pcidev->mem_resource[] is
not populated when the device is initialized for secondary process.

Initialize pcidev->mem_resource[] with pci-bar mapped addresses.

Signed-off-by: Vijaya Mohan Guvva <vijay1054@gmail.com>
---
 drivers/bus/pci/pci_common_uio.c | 1 +
 1 file changed, 1 insertion(+)
  

Comments

Ferruh Yigit March 6, 2020, 12:28 p.m. UTC | #1
On 3/6/2020 12:02 AM, Vijaya Mohan Guvva wrote:
> For pci devices presented through igb_uio, pcidev->mem_resource[] is
> not populated when the device is initialized for secondary process.
> 
> Initialize pcidev->mem_resource[] with pci-bar mapped addresses.
> 
> Signed-off-by: Vijaya Mohan Guvva <vijay1054@gmail.com>

Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
  
Thomas Monjalon March 31, 2020, 1:54 a.m. UTC | #2
06/03/2020 13:28, Ferruh Yigit:
> On 3/6/2020 12:02 AM, Vijaya Mohan Guvva wrote:
> > For pci devices presented through igb_uio, pcidev->mem_resource[] is
> > not populated when the device is initialized for secondary process.
> > 
> > Initialize pcidev->mem_resource[] with pci-bar mapped addresses.
> > 
> > Signed-off-by: Vijaya Mohan Guvva <vijay1054@gmail.com>
> 
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>

Do you mean secondary process never worked with igb_uio?
Or is there a specific case?
What is the root cause?
Should it be backported to stable?
  
Vijaya Mohan Guvva March 31, 2020, 2:12 a.m. UTC | #3
Hi Thomas,
As long as pmd or application doesn't access
dev->mem_resource[i].addr, secondary process works with igb_uio.
But for pci devices like crypto_qat, pmd checks for
dev->mem_resource[i].addr and bails out if the address is null.

Root cause is, not initializing the mapped address in rte_pcidev when
device is exposed through igb_uio.

Thanks,
Vijay

On Mon, 30 Mar 2020 at 18:54, Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 06/03/2020 13:28, Ferruh Yigit:
> > On 3/6/2020 12:02 AM, Vijaya Mohan Guvva wrote:
> > > For pci devices presented through igb_uio, pcidev->mem_resource[] is
> > > not populated when the device is initialized for secondary process.
> > >
> > > Initialize pcidev->mem_resource[] with pci-bar mapped addresses.
> > >
> > > Signed-off-by: Vijaya Mohan Guvva <vijay1054@gmail.com>
> >
> > Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> Do you mean secondary process never worked with igb_uio?
> Or is there a specific case?
> What is the root cause?
> Should it be backported to stable?
>
>
  
Thomas Monjalon March 31, 2020, 9:11 a.m. UTC | #4
31/03/2020 04:12, vijay mohan:
> On Mon, 30 Mar 2020 at 18:54, Thomas Monjalon <thomas@monjalon.net> wrote:
> > 06/03/2020 13:28, Ferruh Yigit:
> > > On 3/6/2020 12:02 AM, Vijaya Mohan Guvva wrote:
> > > > For pci devices presented through igb_uio, pcidev->mem_resource[] is
> > > > not populated when the device is initialized for secondary process.
> > > >
> > > > Initialize pcidev->mem_resource[] with pci-bar mapped addresses.
> > > >
> > > > Signed-off-by: Vijaya Mohan Guvva <vijay1054@gmail.com>
> > >
> > > Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >
> > Do you mean secondary process never worked with igb_uio?
> > Or is there a specific case?
> 
> As long as pmd or application doesn't access
> dev->mem_resource[i].addr, secondary process works with igb_uio.
> But for pci devices like crypto_qat, pmd checks for
> dev->mem_resource[i].addr and bails out if the address is null.
> 
> > What is the root cause?
> 
> Root cause is, not initializing the mapped address in rte_pcidev when
> device is exposed through igb_uio.

So the issue has always been there?
In this case, you should specify the origin commit in "Fixes:" line.

> > Should it be backported to stable?

I think it needs to be backported. So please add Cc: stable@dpdk.org
in the commit log.
  

Patch

diff --git a/drivers/bus/pci/pci_common_uio.c b/drivers/bus/pci/pci_common_uio.c
index 7ea73db..f4dca9d 100644
--- a/drivers/bus/pci/pci_common_uio.c
+++ b/drivers/bus/pci/pci_common_uio.c
@@ -70,6 +70,7 @@ 
 				}
 				return -1;
 			}
+			dev->mem_resource[i].addr = mapaddr;
 		}
 		return 0;
 	}