On Tue, Sep 08, 2020 at 12:02:53PM +0200, Gerd Hoffmann wrote: > > > > The comments I've found suggest very much not ... Or is that all very > > > > old stuff only that no one cares about anymore? > > > > > > I think these days it is possible to override dma_ops per device, which > > > in turn allows virtio to deal with the quirks without the rest of the > > > kernel knowing about these details. > > > > > > I also think virtio-gpu can drop the virtio_has_dma_quirk() checks, just > > > use the dma api path unconditionally and depend on virtio core having > > > setup dma_ops in a way that it JustWorks[tm]. I'll look into that next. > > > > The comment above vring_use_dma_api() suggests that this has not yet > > happened, that's why I'm asking. > > Hmm, wading through the code, seems it indeed happen yet, even though my > testing didn't show any issues. Probably pure luck because devices and > cpus have the same memory view on x86. Guess I need to try this on > ppc64 to see it actually failing ... > > So dropping the virtio_has_dma_quirk() checks isn't going to fly. > > Using dma_max_mapping_size() should be fine though. It might use a > lower limit than needed for virtio, but it should not break things. Makes sense. On this patch here: Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> And I guess would be good if virtio pushes a bit more towards using the dma api abstraction fully so we can get rid of these hacks. Virtio feels like a driver that really should be using dma-api and not dig around behind it because "it' makes stuff 0.5% faster" or so, since being virtualized it's already not the king of speed anyway :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
