linux-kernel - RE: [PATCH] PCI: Blacklist AMD Stoney GPU devices for ATS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR12MB15181A0AC24BC60C4579742D9C350@MWHPR12MB1518.namprd12.prod.outlook.com>
Date:   Wed, 29 Mar 2017 07:15:42 +0000
From:   "Nath, Arindam" <Arindam.Nath@....com>
To:     'Joerg Roedel' <jroedel@...e.de>,
        "Deucher, Alexander" <Alexander.Deucher@....com>
CC:     'Joerg Roedel' <joro@...tes.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Daniel Drake <drake@...lessm.com>
Subject: RE: [PATCH] PCI: Blacklist AMD Stoney GPU devices for ATS

>-----Original Message-----
>From: 'Joerg Roedel' [mailto:jroedel@...e.de]
>Sent: Wednesday, March 29, 2017 3:56 AM
>To: Deucher, Alexander
>Cc: 'Joerg Roedel'; Bjorn Helgaas; linux-pci@...r.kernel.org; linux-
>kernel@...r.kernel.org; Daniel Drake; Nath, Arindam
>Subject: Re: [PATCH] PCI: Blacklist AMD Stoney GPU devices for ATS
>
>On Tue, Mar 28, 2017 at 09:13:23PM +0000, Deucher, Alexander wrote:
>> If I understand Arindam's patch correctly, it only flushes TLB entries
>> for domains in the flush queue whereas the previous behavior was to
>> flush all domains.  If there was no TLB flush in the queue for that
>> domain, could flushing it cause a problem?
>
>No, that can't cause a problem. An io/tlb flush for the device is just a
>message that the device should invalidate its own tlb. The device can't
>know and doesn't need to know whether the page-tables it used to fill
>the tlb really changed.

Joerg, as per my limited understanding of ATS, the ATC will respond to invalidation requests after making sure there are no in-flight DMA transactions with the address requested by IOMMU to be invalidated. Now since the IOMMU was sending invalidate command to GPU even though there was no explicit page unmapping request from the graphics subsystem, we _might_ end up in a situation where the ATC takes longer than the invalidation timeout to respond to IOMMU.

With the patch I provided, since only those domains who have actually requested for unmapping pages have been added to the flush queue, we send TLB invalidation commands to only those specific domains. This avoids sending invalidation command to GPU ATC every single flush.

I do agree that the Stoney might have some issue which causes it not to be able complete the invalidation command in time since we are not observing the issue on CZ and other ASICs.

Thanks,
Arindam

>
>As it looks, the problem we are seeing here is that we are sending a
>large amount of these requests to the GPU device, and wait for its
>completion every time. This shouldn't be a problem for ATS devices, but
>the GPU here seems to fail at some point and doesn't answer to the
>invalidation request anymore, causing the completion-wait loop timeouts.
>
>Arindam's patch makes the high flush-frequency less likely, but it can
>still happen, depending on how the GPU is used. So its the best to
>keep ATS disabled on the device as it doesn't work correctly and we risk
>running in the same problem again when we leave it enabled and just make
>the trigger less likely.
>
>
>	Joerg