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).
WARNING: multiple messages have this Message-ID (diff)
From: "hch@lst.de" <hch@lst.de>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Deepak Singh Rawat <drawat@vmware.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"hch@lst.de" <hch@lst.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.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)
Message-ID: <20190409095740.a1FucQ3mQCWguPhXMDa6tLcTz2KrXrKafF3RW0N5ybw@z> (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).
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-04-09 9:57 UTC|newest]
Thread overview: 33+ 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 ` Christoph Hellwig
2019-04-08 10:55 ` [PATCH] Revert "drm/vmwgfx: Improve on IOMMU detection" Christoph Hellwig
2019-04-08 10:55 ` Christoph Hellwig
[not found] ` <20190408105525.5493-2-hch-jcswGhMUV9g@public.gmane.org>
2019-04-08 20:05 ` Thomas Hellstrom via iommu
2019-04-08 20:05 ` Thomas Hellstrom
2019-04-08 20:05 ` Thomas Hellstrom via iommu
2019-04-08 18:47 ` revert dma direct internals abuse Thomas Hellstrom
2019-04-08 18:47 ` Thomas Hellstrom via iommu
2019-04-09 9:57 ` hch [this message]
2019-04-09 9:57 ` hch
[not found] ` <20190409095740.GE6827-jcswGhMUV9g@public.gmane.org>
2019-04-09 13:04 ` Thomas Hellstrom via iommu
2019-04-09 13:04 ` Thomas Hellstrom
2019-04-09 13:04 ` Thomas Hellstrom via iommu
2019-04-09 13:31 ` hch
2019-04-09 13:31 ` hch
2019-04-09 14:17 ` Thomas Hellstrom
2019-04-09 14:17 ` Thomas Hellstrom via iommu
2019-04-09 15:25 ` hch
2019-04-09 15:25 ` hch
[not found] ` <20190409152538.GA12816-jcswGhMUV9g@public.gmane.org>
2019-04-09 17:24 ` Thomas Hellstrom via iommu
2019-04-09 17:24 ` Thomas Hellstrom
2019-04-09 17:24 ` Thomas Hellstrom via iommu
2019-04-10 6:43 ` hch
2019-04-10 6:43 ` hch
[not found] ` <20190410064359.GC5543-jcswGhMUV9g@public.gmane.org>
2019-04-10 15:01 ` Thomas Hellstrom via iommu
2019-04-10 15:01 ` Thomas Hellstrom
2019-04-10 15:01 ` Thomas Hellstrom via iommu
[not found] ` <0c897b24b234f8d42ef597dbe31fa8293519a4b2.camel-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2019-04-22 17:56 ` hch-jcswGhMUV9g
2019-04-22 17:56 ` hch
2019-04-22 17:56 ` hch
2019-04-23 12:26 ` Thomas Hellstrom
2019-04-23 12:26 ` Thomas Hellstrom via iommu
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.