[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190426150433.GA19930@lst.de>
Date: Fri, 26 Apr 2019 17:04:33 +0200
From: Christoph Hellwig <hch@....de>
To: Lu Baolu <baolu.lu@...ux.intel.com>
Cc: Christoph Hellwig <hch@....de>,
David Woodhouse <dwmw2@...radead.org>,
Joerg Roedel <joro@...tes.org>, ashok.raj@...el.com,
jacob.jun.pan@...el.com, alan.cox@...el.com, kevin.tian@...el.com,
mika.westerberg@...ux.intel.com, pengfei.xu@...el.com,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 02/10] swiotlb: Factor out slot allocation and free
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
> This is not VT-d specific. It's just how generic IOMMU works.
>
> Normally, IOMMU works in paging mode. So if a driver issues DMA with
> IOVA 0xAAAA0123, IOMMU can remap it with a physical address 0xBBBB0123.
> But we should never expect IOMMU to remap 0xAAAA0123 with physical
> address of 0xBBBB0000. That's the reason why I said that IOMMU will not
> work there.
Well, with the iommu it doesn't happen. With swiotlb it obviosuly
can happen, so drivers are fine with it. Why would that suddenly
become an issue when swiotlb is called from the iommu code?
Powered by blists - more mailing lists