[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 06/16] iommu/dma: extend iommu_dma_*map_phys API to handle MMIO memory



On Mon, Aug 04, 2025 at 03:42:40PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@xxxxxxxxxx>
> 
> Combine iommu_dma_*map_phys with iommu_dma_*map_resource interfaces in
> order to allow single phys_addr_t flow.

Some later patch deletes iommu_dma_map_resource() ? Mention that plan here?

> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1193,12 +1193,17 @@ static inline size_t iova_unaligned(struct 
> iova_domain *iovad, phys_addr_t phys,
>  dma_addr_t iommu_dma_map_phys(struct device *dev, phys_addr_t phys, size_t 
> size,
>               enum dma_data_direction dir, unsigned long attrs)
>  {
> -     bool coherent = dev_is_dma_coherent(dev);
> -     int prot = dma_info_to_prot(dir, coherent, attrs);
>       struct iommu_domain *domain = iommu_get_dma_domain(dev);
>       struct iommu_dma_cookie *cookie = domain->iova_cookie;
>       struct iova_domain *iovad = &cookie->iovad;
>       dma_addr_t iova, dma_mask = dma_get_mask(dev);
> +     bool coherent;
> +     int prot;
> +
> +     if (attrs & DMA_ATTR_MMIO)
> +             return __iommu_dma_map(dev, phys, size,
> +                             dma_info_to_prot(dir, false, attrs) | 
> IOMMU_MMIO,
> +                             dma_get_mask(dev));

I realize that iommu_dma_map_resource() doesn't today, but shouldn't
this be checking for swiotlb:

        if (dev_use_swiotlb(dev, size, dir) &&
            iova_unaligned(iovad, phys, size)) {

Except we have to fail for ATTR_MMIO?

Now that we have ATTR_MMIO, should dma_info_to_prot() just handle it
directly instead of open coding the | IOMMU_MMIO and messing with the
coherent attribute?

Jason



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.