From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943873AbdEZP7I (ORCPT ); Fri, 26 May 2017 11:59:08 -0400 Received: from mail-sn1nam02on0047.outbound.protection.outlook.com ([104.47.36.47]:30912 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S940894AbdEZP7F (ORCPT ); Fri, 26 May 2017 11:59:05 -0400 From: "Deucher, Alexander" To: "'David Woodhouse'" , "'Joerg Roedel'" , "Bridgman, John" , "Suthikulpanit, Suravee" CC: "'Joerg Roedel'" , Bjorn Helgaas , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Daniel Drake , Samuel Sieb Subject: RE: [PATCH v2] PCI: Add ATS-disable quirk for AMD Stoney GPUs Thread-Topic: [PATCH v2] PCI: Add ATS-disable quirk for AMD Stoney GPUs Thread-Index: AQHSr6vHBMNtgiI4D0yTU57sgEnxvKG6HXRQgCoDoICAHntcoIAA2DoAgANZfqCAABD6AIAAJJiQ Date: Fri, 26 May 2017 15:59:01 +0000 Message-ID: References: <1491575538-22694-1-git-send-email-joro@8bytes.org> <1493893297.4904.71.camel@infradead.org> <20170524084450.GB12353@suse.de> <1495803280.26190.37.camel@infradead.org> In-Reply-To: <1495803280.26190.37.camel@infradead.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: infradead.org; dkim=none (message not signed) header.d=none;infradead.org; dmarc=none action=none header.from=amd.com; x-originating-ip: [165.204.55.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;BN6PR12MB1729;20:0Ky8G/+v8AXM+VD2bZ3F4puv6hywEbO1dqJXI6DXbGSlLTvvIyViAQ6ho7pc5a4WdPg7uxvlRP3dq46C4scsOVcAGMheYDTgO3vPN2ibvpSpHRDjlwoOwBALf84FNyZUZd31RpvD7yd5b/9DBhyCQojp8rMKYtnpCe7+cFF4i/CV9v6eoj9Onz5XZIAFCC10896HBOojaOKKgb0LaxumPnRyCXDykP2ehyazlQ9bMjCsS/HHzjC8lCItjeZfMcij x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(979002)(6009001)(39410400002)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(377424004)(377454003)(13464003)(24454002)(72206003)(3660700001)(4326008)(2900100001)(189998001)(38730400002)(2950100002)(229853002)(7696004)(551934003)(478600001)(6636002)(93886004)(6246003)(53936002)(3280700002)(8676002)(33656002)(74316002)(66066001)(81166006)(6436002)(77096006)(50986999)(54356999)(5660300001)(76176999)(6506006)(2906002)(53546009)(54906002)(14454004)(99286003)(9686003)(55016002)(102836003)(25786009)(86362001)(6116002)(3846002)(122556002)(305945005)(8936002)(7736002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR12MB1729;H:BN6PR12MB1652.namprd12.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; x-ms-traffictypediagnostic: BN6PR12MB1729: x-ms-office365-filtering-correlation-id: 800c76b4-84e4-4807-b4b1-08d4a45020be x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:BN6PR12MB1729; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700061)(100105000095)(100000701061)(100105300095)(100000702061)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703061)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(6072148)(100000704061)(100105200095)(100000705061)(100105500095);SRVR:BN6PR12MB1729;BCL:0;PCL:0;RULEID:(100000800061)(100110000095)(100000801061)(100110300095)(100000802061)(100110100095)(100000803061)(100110400095)(100000804061)(100110200095);SRVR:BN6PR12MB1729; x-forefront-prvs: 031996B7EF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2017 15:59:01.7418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1729 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v4QFxIf9030147 > -----Original Message----- > From: David Woodhouse [mailto:dwmw2@infradead.org] > Sent: Friday, May 26, 2017 8:55 AM > To: Deucher, Alexander; 'Joerg Roedel' > Cc: 'Joerg Roedel'; Bjorn Helgaas; linux-pci@vger.kernel.org; linux- > kernel@vger.kernel.org; Daniel Drake; Samuel Sieb > Subject: Re: [PATCH v2] PCI: Add ATS-disable quirk for AMD Stoney GPUs > > On Fri, 2017-05-26 at 11:57 +0000, Deucher, Alexander wrote: > > > > FWIW, the GPU driver does not actually use ATS at the moment so I > > don't think we should see any ATS transactions. > > That's a confusing sentence. The "GPU driver", if you mean software > running in the OS, wouldn't be expected to have anything to do with > ATS. > > ATS is something that the CPU itself (or its DMA engine) would do. > Instead of just performing a DMA transaction to a given bus address, > and letting the IOMMU do the translation, the hardware might choose to > first perform an IOTLB lookup, and then later do the actual DMA > transaction to the pre-translated, raw physical address. Which kind of > makes a mockery of any kind of protection the IOMMU is supposed to give > you, but does shave a cycle or two of latency off the DMA when it > finally happens, since the translation can be done in advance. + John, Suravee Full disclosure, I'm not by any means an expert with ATS. I guess I'm thinking of PRI support rather than ATS per se. On the GPU side the GPU's memory controller has multiple paths to system memory, the non-ATS/PRI path and the ATS/PRI path. The GPU has its own integrated MMU to virtualize the GPU's internal address space per GPU client. The non-ATS/PRI path uses the GPU's MMU and is just "regular" dma to addresses potentially translated by the IOMMU just like any other device that may not have ATS support. The system memory has to be resident because if the GPU faults, it can't retry the transaction. For the ATS/PRI path, the GPU's MMU is bypassed and PASIDs need to be setup on the IOMMU for each client, but once done, transactions that use that interface support retries on GPU page faults (after the OS had paged the memory in and the IOMMU tables been updated) and other features. I think only the ATS/PRI case uses the ATC on the end point. John, Suravee, correct me if I'm wrong. Alex