Re: [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited

2019-12-06 Thread Thomas Hellstrom via iommu
Hi, Christoph. On Wed, 2019-12-04 at 14:03 +0100, Christoph Hellwig wrote: > Devices that are forced to DMA through swiotlb need to be treated as > if > they are addressing limited. > > Signed-off-by: Christoph Hellwig > --- > include/linux/dma-direct.h | 1 + > kernel/dma/direct.c| 8

Re: [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited

2019-11-28 Thread Thomas Hellstrom via iommu
On 11/28/19 8:51 AM, h...@lst.de wrote: > On Wed, Nov 27, 2019 at 06:22:57PM +, Thomas Hellstrom wrote: >>> bool dma_addressing_limited(struct device *dev) >>> { >>> + if (force_dma_unencrypted(dev)) >>> + return true; >>> return min_not_zero(dma_get_mask(dev), dev->bus_dma_li

Re: [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited

2019-11-27 Thread Thomas Hellstrom via iommu
Hi, On Wed, 2019-11-27 at 15:40 +0100, Christoph Hellwig wrote: > Devices that are forced to DMA through unencrypted bounce buffers > need to be treated as if they are addressing limited. > > Signed-off-by: Christoph Hellwig > --- > kernel/dma/mapping.c | 2 ++ > 1 file changed, 2 insertions(+)

Re: revert dma direct internals abuse

2019-04-23 Thread Thomas Hellstrom via iommu
Hi, Christoph, On Mon, 2019-04-22 at 19:56 +0200, h...@lst.de wrote: > On Wed, Apr 10, 2019 at 03:01:14PM +, Thomas Hellstrom wrote: > > > So can you please respin a version acceptable to you and submit > > > it > > > for 5.1 ASAP? Otherwise I'll need to move ahead with the simple > > > rever

Re: revert dma direct internals abuse

2019-04-10 Thread Thomas Hellstrom via iommu
On Wed, 2019-04-10 at 08:43 +0200, h...@lst.de wrote: > On Tue, Apr 09, 2019 at 05:24:48PM +, Thomas Hellstrom wrote: > > > Note that this only affects external, untrusted devices. But > > > that > > > may include eGPU, > > > > What about discrete graphics cards, like Radeon and Nvidia? Who >

Re: revert dma direct internals abuse

2019-04-09 Thread Thomas Hellstrom via iommu
On Tue, 2019-04-09 at 17:25 +0200, h...@lst.de wrote: > On Tue, Apr 09, 2019 at 02:17:40PM +, Thomas Hellstrom wrote: > > If that's the case, I think most of the graphics drivers will stop > > functioning. I don't think people would want that, and even if the > > graphics drivers are "to blame"

Re: revert dma direct internals abuse

2019-04-09 Thread Thomas Hellstrom via iommu
On Tue, 2019-04-09 at 15:31 +0200, h...@lst.de wrote: > On Tue, Apr 09, 2019 at 01:04:51PM +, Thomas Hellstrom wrote: > > On the VMware platform we have two possible vIOMMUS, the AMD iommu > > and > > Intel VTD, Given those conditions I belive the patch is > > functionally > > correct. We can't

Re: revert dma direct internals abuse

2019-04-09 Thread Thomas Hellstrom via iommu
On Tue, 2019-04-09 at 11:57 +0200, h...@lst.de wrote: > On Mon, Apr 08, 2019 at 06:47:52PM +, 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 > instruc

Re: [PATCH] Revert "drm/vmwgfx: Improve on IOMMU detection"

2019-04-08 Thread Thomas Hellstrom via iommu
On Mon, 2019-04-08 at 12:55 +0200, Christoph Hellwig wrote: > This reverts commit 9ddac734aa310c5fbc0ec93602335d2a39092451. IMHO, rather than reverting, I'd like to see the dma API provide a function telling us whether streaming DMA operations are coherent or not. With that we could fix all driv

Re: revert dma direct internals abuse

2019-04-08 Thread Thomas Hellstrom via iommu
Christoph, On Mon, 2019-04-08 at 12:55 +0200, Christoph Hellwig wrote: > Hi Linus, > > unfortunately it took less than a merge window for the: > > /* > * All the dma_direct_* declarations are here just for the indirect > call bypass, > * and must not be used directly drivers! > */ > > warni