[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MN2PR05MB6141B6D7E28A146EBF9CE79FA1470@MN2PR05MB6141.namprd05.prod.outlook.com>
Date: Thu, 28 Nov 2019 08:02:16 +0000
From: Thomas Hellstrom <thellstrom@...are.com>
To: "hch@....de" <hch@....de>
CC: "thomas.lendacky@....com" <thomas.lendacky@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"christian.koenig@....com" <christian.koenig@....com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH 2/2] dma-mapping: force unencryped devices are always
addressing limited
On 11/28/19 8:51 AM, hch@....de wrote:
> On Wed, Nov 27, 2019 at 06:22:57PM +0000, 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_limit) <
>>> dma_get_required_mask(dev);
>>> }
>> Any chance to have the case
>>
>> (swiotlb_force == SWIOTLB_FORCE)
>>
>> also included?
> We have a hard time handling that in generic code. Do we have any
> good use case for SWIOTLB_FORCE not that we have force_dma_unencrypted?
> I'd love to be able to get rid of it..
>
IIRC the justification for it is debugging. Drivers that don't do
syncing correctly or have incorrect assumptions of initialization of DMA
memory will not work properly when SWIOTLB is forced. We recently found
a vmw_pvscsi device flaw that way...
/Thomas
Powered by blists - more mailing lists