> -----Original Message-----
> From: David Marchand <david.march...@redhat.com>
> Sent: Monday, July 3, 2023 3:48 PM
> To: Li, Miao <miao...@intel.com>
> Cc: dev@dpdk.org; sta...@dpdk.org; Maxime Coquelin
> <maxime.coque...@redhat.com>; Xia, Chenbo <chenbo....@intel.com>
> Subject: Re: [PATCH v2 1/2] net/virtio: fix legacy device IO port map in
> secondary process
>
> On Thu, Jun 29, 2023 at 4:27 AM Miao Li <miao...@intel.com> wrote:
> >
> > When doing IO port map for legacy device in secondary process,
> > vfio_cfg setup for legacy device like vfio_group_fd and vfio_dev_fd
> > is missing. So, in secondary process, rte_pci_map_device is added
> > for legacy device to setup vfio_cfg and fill in region info like in
> > primary process.
>
> I think, in legacy mode, there is no PCI mappable memory.
> So there should be no need for this call to rte_pci_map_device.
>
> What is missing is a vfio setup, is this correct?
> I'd rather see this issue be fixed in the pci_vfio_ioport_map() function.
Thinking about this again: pci_vfio_ioport_map is defined to map specific
ioport so
it does not make sense to do any device setup in such function. Any reason why
we can't call rte_pci_map_device in secondary/legacy? This function
rte_pci_map_device
is defined to set-up device and set up BAR mapping if needed. Secondary process
for any
driver needs set-up device and BAR mapping again (right?). For legacy device it
can skip
the BAR mapping part, which rte_pci_map_device is already doing.
Any comments?
Thanks,
Chenbo
>
>
> >> Fixes: 512e27eeb743 ("net/virtio: move PCI specific dev init to PCI
> ethdev init")
>
> This commit only moved code, and at this point, there was no need for
> a call to rte_pci_map_device in the secondary process case.
> It seems unlikely this is a faulty change.
>
> The recent addition on the vfio side seems a better culprit, but I am
> fine with being proven wrong :-).
>
>
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Miao Li <miao...@intel.com>
>
>
> --
> David Marchand
