Xuan Zhuo
2023-Apr-11 01:56 UTC
[PATCH vhost v6 08/11] virtio_ring: introduce virtqueue_dma_dev()
On Mon, 10 Apr 2023 08:27:14 -0700, Christoph Hellwig <hch at infradead.org> wrote:> On Mon, Apr 10, 2023 at 01:14:13PM +0800, Jason Wang wrote: > > > But rethink, this is unreliable. Some platforms have returned their own ops, > > > including X86. > > > > > > Because the priority of dev->dma_ops is higher than get_arch_dma_ops(), we > > > should not let dev->dma_ops be null. We should define a set of dma_ops to > > > actively implement direct dMA. > > > > Then this will duplicate with existing DMA API helpers. Could we tweak > > the sparc or introduce a new flag for the device structure then the > > DMA API knows it needs to use direct mapping? > > > > Adding Christoph for more comments. > > Code outside of the core kernel/dma/ code has no business doing > anything with the dma_ops.Do you mean we should not change the dma_ops from the outside of the core kernel/dma/? How about adding one new "dma_direct" to struct devive? --- a/include/linux/dma-map-ops.h +++ b/include/linux/dma-map-ops.h @@ -88,6 +88,9 @@ struct dma_map_ops { static inline const struct dma_map_ops *get_dma_ops(struct device *dev) { + if (dev->dma_direct) + return NULL; + if (dev->dma_ops) return dev->dma_ops; return get_arch_dma_ops(); Thanks.> WTF is going on?
Jason Wang
2023-Apr-11 02:09 UTC
[PATCH vhost v6 08/11] virtio_ring: introduce virtqueue_dma_dev()
On Tue, Apr 11, 2023 at 10:01?AM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote:> > On Mon, 10 Apr 2023 08:27:14 -0700, Christoph Hellwig <hch at infradead.org> wrote: > > On Mon, Apr 10, 2023 at 01:14:13PM +0800, Jason Wang wrote: > > > > But rethink, this is unreliable. Some platforms have returned their own ops, > > > > including X86. > > > > > > > > Because the priority of dev->dma_ops is higher than get_arch_dma_ops(), we > > > > should not let dev->dma_ops be null. We should define a set of dma_ops to > > > > actively implement direct dMA. > > > > > > Then this will duplicate with existing DMA API helpers. Could we tweak > > > the sparc or introduce a new flag for the device structure then the > > > DMA API knows it needs to use direct mapping? > > > > > > Adding Christoph for more comments. > > > > Code outside of the core kernel/dma/ code has no business doing > > anything with the dma_ops. > > Do you mean we should not change the dma_ops from the outside of the core > kernel/dma/? > > How about adding one new "dma_direct" to struct devive? > > --- a/include/linux/dma-map-ops.h > +++ b/include/linux/dma-map-ops.h > @@ -88,6 +88,9 @@ struct dma_map_ops { > > static inline const struct dma_map_ops *get_dma_ops(struct device *dev) > { > + if (dev->dma_direct) > + return NULL; > + > if (dev->dma_ops) > return dev->dma_ops; > return get_arch_dma_ops(); > > > Thanks. > > > > > WTF is going on?We want to support AF_XDP for virtio-net. It means AF_XDP needs to know the dma device to perform DMA mapping. So we introduce a helper to expose the dma dev of the virtio device. This works fine as long as VIRTIO_F_ACCESS_PLATFORM is negotiated. But when it is not, the virtio driver needs to use a physical address so we want to expose the virtio device without dma_ops in the hope that it will go for direct mapping where the physical address is used. But it may not work on some specific setups (arches that assume an IOMMU or have arch dma ops). Thanks>
Christoph Hellwig
2023-Apr-11 03:26 UTC
[PATCH vhost v6 08/11] virtio_ring: introduce virtqueue_dma_dev()
On Tue, Apr 11, 2023 at 09:56:19AM +0800, Xuan Zhuo wrote:> Do you mean we should not change the dma_ops from the outside of the core > kernel/dma/?Basically, yes. That plus probing for the IOMMU drivers.> How about adding one new "dma_direct" to struct devive?Why would we? Can you please explain what you're even trying to do? But checking a dma_direct flag for sure isn't the solution.