On Tue, Apr 11, 2023 at 10:01 AM Xuan Zhuo <xuanzhuo@xxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 10 Apr 2023 08:27:14 -0700, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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
>
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
