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

[Thomas Monjalon]

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.