On Fri, Jun 12, 2020 at 12:16 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Fri, Jun 12, 2020 at 11:47:55AM +0200, Thomas Zimmermann wrote: > > Hi > > > > Am 12.06.20 um 03:36 schrieb Gurchetan Singh: > > > This is useful for the next patch. Also, should we only unmap the > > > amount entries that we mapped with the dma-api? > > > > It looks like you're moving virtio code into shmem. > > Well, not really. > > virtio has -- for historical reasons -- the oddity that it may or may > not need to dma_map resources, depending on device configuration. > Initially virtio went with "it's just a vm, lets simply operate on > physical ram addresses". That shortcut turned out to be a bad idea > later on, especially with the arrival of iommu emulation support in > qemu. But we couldn't just scratch it for backward compatibility > reasons. See virtio_has_iommu_quirk(). > > This just allows to enable/disable dma_map, I guess to fix some fallout > from recent shmem helper changes (Gurchetan, that kind of stuff should > be mentioned in cover letter and commit messages). > > I'm not sure virtio actually needs that patch though. I *think* doing > the dma_map+dma_unmap unconditionally, but then ignore the result in > case we don't need it should work. And it shouldn't be a horrible > performance hit either, in case we don't have a (virtual) iommu in the > VM dma mapping is essentially a nop ... Yeah that sounds a lot more like a clean solution, instead of adding random flags and stuff all over helpers for each edge-case. The sgtable still has the struct pages, so just picking the right one in virtio code seems a lot cleaner separation of concerns. -Daniel > > take care, > Gerd > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
