On Tue, Aug 07, 2018 at 07:26:35AM +1000, Benjamin Herrenschmidt wrote: > > I think Christoph merely objects to the specific implementation. If > > instead you do something like tweak dev->bus_dma_mask for the virtio > > device I think he won't object. > > Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ?
It will be new in 4.19: http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/f07d141fe9430cdf9f8a65a87c41 > So, something like that would be a possibility, but the problem is that > the current virtio (guest side) implementation doesn't honor this when > not using dma ops and will not use dma ops if not using iommu, so back > to square one. > > Christoph seems to be wanting to use a flag in the interface to make > the guest use dma_ops which is what I don't understand. As-is virtio devices are very clearly and explcitly defined to use physical addresses in the spec. dma ops will often do platform based translations (iommu, offsets), so we can't just use the plaform default dma ops and will need to opt into them. > What would be needed then would be something along the lines of virtio > noticing that dma_mask isn't big enough to cover all of memory (which > isn't something generic code can easily do here for various reasons I > can elaborate if you want, but that specific test more/less has to be > arch specific), and in that case, force itself to use DMA ops routed to > swiotlb. > > I'd rather have arch code do the bulk of that work, don't you think ? There is nothing architecture specific about that. I've been working hard to remove all the bullshit architectures have done in their DMA ops and consolidating them into common code based on rules. The last thing I want is another vector for weird underspecified arch interfaction with DMA ops, which is exactly what your patch below does.