Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Thomas Hellstrom <thellstrom@vmware.com>
To:     "hch@lst.de" <hch@lst.de>
CC:     "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "christian.koenig@amd.com" <christian.koenig@amd.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH 2/2] dma-mapping: force unencryped devices are always
 addressing limited
Thread-Topic: [PATCH 2/2] dma-mapping: force unencryped devices are always
 addressing limited
Thread-Index: AQHVpTCUSCVjXh+W+0SSCl6TSmyYRg==
Date:   Thu, 28 Nov 2019 08:02:16 +0000
Message-ID: <MN2PR05MB6141B6D7E28A146EBF9CE79FA1470@MN2PR05MB6141.namprd05.prod.outlook.com>
References: <20191127144006.25998-1-hch@lst.de>
 <20191127144006.25998-3-hch@lst.de>
 <a95d9115fc2a80de2f97f001bbcd9aba6636e685.camel@vmware.com>
 <20191128075153.GD20659@lst.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: vmware.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b3653bef-8f4f-40f5-577d-08d773d94934
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2019 08:02:16.8369
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0MmJ5kec9vsnBAnVI86Nno4Bb1VP2+Y5sxvpn1qsuJnmy8ZA1ZWq5DFS7zUqaga3UygpOGMp3DIFnEcOKAIa6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6125
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11/28/19 8:51 AM, hch@lst.de wrote:=0A=
> On Wed, Nov 27, 2019 at 06:22:57PM +0000, Thomas Hellstrom wrote:=0A=
>>>  bool dma_addressing_limited(struct device *dev)=0A=
>>>  {=0A=
>>> +	if (force_dma_unencrypted(dev))=0A=
>>> +		return true;=0A=
>>>  	return min_not_zero(dma_get_mask(dev), dev->bus_dma_limit) <=0A=
>>>  			    dma_get_required_mask(dev);=0A=
>>>  }=0A=
>> Any chance to have the case=0A=
>>=0A=
>> (swiotlb_force =3D=3D SWIOTLB_FORCE)=0A=
>>=0A=
>> also included?=0A=
> We have a hard time handling that in generic code.  Do we have any=0A=
> good use case for SWIOTLB_FORCE not that we have force_dma_unencrypted?=
=0A=
> I'd love to be able to get rid of it..=0A=
>=0A=
IIRC the justification for it is debugging. Drivers that don't do=0A=
syncing correctly or have incorrect assumptions of initialization of DMA=0A=
memory will not work properly when SWIOTLB is forced. We recently found=0A=
a vmw_pvscsi device flaw that way...=0A=
=0A=
/Thomas=0A=
=0A=
=0A=
=0A=