search for: virtio_direct_map_page

...for all virtio devices which would not > + * either bring in their own DMA OPS from architecture or they would not > + * like to use architecture specific IOMMU based DMA OPS because QEMU > + * expects GPA instead of an IOVA in absence of VIRTIO_F_IOMMU_PLATFORM. > + */ > +dma_addr_t virtio_direct_map_page(struct device *dev, struct page *page, > + unsigned long offset, size_t size, > + enum dma_data_direction dir, > + unsigned long attrs) All these functions should probably be marked static. > +void virtio_direct_unmap_page(struct device *hwdev, dma_addr_t dev_addr, &...

...efines DMA API structure for all virtio devices which would not + * either bring in their own DMA OPS from architecture or they would not + * like to use architecture specific IOMMU based DMA OPS because QEMU + * expects GPA instead of an IOVA in absence of VIRTIO_F_IOMMU_PLATFORM. + */ +dma_addr_t virtio_direct_map_page(struct device *dev, struct page *page, + unsigned long offset, size_t size, + enum dma_data_direction dir, + unsigned long attrs) +{ + return page_to_phys(page) + offset; +} + +void virtio_direct_unmap_page(struct device *hwdev, dma_addr_t dev_addr, + size_t size, enum dma_data_...

This patch series is the follow up on the discussions we had before about the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation for virito devices (https://patchwork.kernel.org/patch/10417371/). There were suggestions about doing away with two different paths of transactions with the host/QEMU, first being the direct GPA and the other being the DMA API based translations.

This patch series is the follow up on the discussions we had before about the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation for virito devices (https://patchwork.kernel.org/patch/10417371/). There were suggestions about doing away with two different paths of transactions with the host/QEMU, first being the direct GPA and the other being the DMA API based translations.