[PATCH 1/2] drm/shmem: add support for per object dma api operations

[Daniel Vetter]

On Fri, Jun 12, 2020 at 12:16 PM Gerd Hoffmann <kraxel at redhat.com> 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