[dpdk-dev] [PATCH v7 7/9] linuxapp/eal_vfio: honor iova mode before mapping

Thomas Monjalon thomas at monjalon.net
Fri Nov 3 11:54:45 CET 2017


03/11/2017 11:44, Jonas Pfefferle1:
> Thomas Monjalon <thomas at monjalon.net> wrote on 11/03/2017 11:28:10 AM:
> > 03/11/2017 10:56, Jonas Pfefferle1:
> > > Thomas Monjalon <thomas at monjalon.net> wrote on 11/02/2017 11:17:10 AM:
> > > > > 26/10/2017 14:57, Jonas Pfefferle1:
> > > > > >
> > > > > > Hi @all
> > > > > >
> > > > > > I just stumbled upon this patch while testing on POWER.
> RTE_IOVA_VA
> > > > will
> > > > > > not work for the sPAPR code since the dma window size is
> currently
> > > > > > determined by the physical address only.
> > > > >
> > > > > Is it    affecting POWER8?
> > > >
> > > > It is.
> > > >
> > > > >
> > > > > > I'm preparing a patch to address this.
> > > > >
> > > > > Any news?
> > > > > Can you use virtual addresses?
> > > >
> > > > After a long discussion with Alexey (CC) we came to the conclusion
> that
> > > > with the current sPAPR iommu driver we cannot use virtual addresses
> since
> > > > the iova is restricted to lay in the DMA window which itself is
> > > restricted
> > > > to physical RAM addresses resp. with the current code 0 to hotplug
> memory
> > > > max. However, Alexey is working on a patch to lift this restriction
> on
> > > the
> > > > DMA window size which should allow us to do VA:VA mappings in the
> future.
> > > > For now we should fall back to PA in the dynamic iova mode check. I
> will
> > > > send an according patch later today.
> > >
> > > I looked into this yesterday but I'm not sure what the right solution
> is
> > > here.
> > > At the time rte_pci_get_iommu_class is called we already know which
> IOMMU
> > > types are supported because vfio_get_container_fd resp.
> > > vfio_has_supported_extensions  has been called however we do not know
> which
> > > one is going to be used (Decided later in vfio_setup_device resp.
> > > vfio_set_iommu_type). We can choose a iova mode which is supported by
> all
> > > types but if the modes are exclusive to the types we have to guess
> which
> > > one is going to be used. Or let the user decide?
> >
> > You can keep the old behaviour, restricting to physical memory,
> > until you support virtual addressing.
> > It can be just a #ifdef RTE_ARCH_PPC_64.
> >
> 
> Ok but we might want to refine this in the future. IMO It looks much
> cleaner
> to decide this on the iommu type plus this would also cover the noiommu
> case without having this extra check reading the sysfs variable.

You are using the word "this" too many times to help me understand :)

Anyway, please send a quick fix today for 17.11.
The RC3 will be probably closed before Monday.



More information about the dev mailing list