From: "hch@lst.de" <hch@lst.de>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "hch@lst.de" <hch@lst.de>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Deepak Singh Rawat <drawat@vmware.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: revert dma direct internals abuse
Date: Tue, 9 Apr 2019 11:57:40 +0200 [thread overview]
Message-ID: <20190409095740.GE6827@lst.de> (raw)
In-Reply-To: <7d5f35da4a6b58639519f0764c7edbfe4dd1ba02.camel@vmware.com>
On Mon, Apr 08, 2019 at 06:47:52PM +0000, Thomas Hellstrom wrote:
> We HAVE discussed our needs, although admittedly some of my emails
> ended up unanswered.
And than you haven't followed up, and instead ignored the layering
instructions and just commited a broken patch?
> We've as you're well aware of had a discussion with the other
> subsystems doing user-space DMA-buffers wanting this functionality from
> the dma api (AMD graphics and RDMA people IIRC). that is a bool that
> tells us whether streaming dma mappings are coherent, and I described
> in detail why we couldn't use the dma_sync_* API and
> dma_alloc_coherent().
And that is not at all what you either check or claim to do in the
changelog (which btw, are two different things).
> The other option we have is to just fail miserably without messages if
> streaming DMA is not coherent, which I think the other drivers might
> do... That's all I'm trying to avoid here. I'd much prefer to have the
> dma API export this bool.
Both DMA direct and non-DMA direct streaming mappings can be either
coherent or incoherent, so your patch doesn't archive that. The
commit log claims the following:
"drm/vmwgfx: Improve on IOMMU detection
instead of relying on intel_iommu_enabled, use the fact that the
dma_map_ops::map_page != dma_direct_map_page"
which has nothing to do with the fact that streaming mappings are
coherent. It also is incorrect as there are direct mapping that
do not use dma_direct_map_page (e.g. on ARM, or x86 with VMD).
next prev parent reply other threads:[~2019-04-09 9:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 10:55 revert dma direct internals abuse Christoph Hellwig
2019-04-08 10:55 ` [PATCH] Revert "drm/vmwgfx: Improve on IOMMU detection" Christoph Hellwig
2019-04-08 20:05 ` Thomas Hellstrom
2019-04-08 18:47 ` revert dma direct internals abuse Thomas Hellstrom
2019-04-09 9:57 ` hch [this message]
2019-04-09 13:04 ` Thomas Hellstrom
2019-04-09 13:31 ` hch
2019-04-09 14:17 ` Thomas Hellstrom
2019-04-09 15:25 ` hch
2019-04-09 17:24 ` Thomas Hellstrom
2019-04-10 6:43 ` hch
2019-04-10 15:01 ` Thomas Hellstrom
2019-04-22 17:56 ` hch
2019-04-23 12:26 ` Thomas Hellstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190409095740.GE6827@lst.de \
--to=hch@lst.de \
--cc=drawat@vmware.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thellstrom@vmware.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox