Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1221895pxb; Fri, 20 Nov 2020 04:27:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJwv/4Ksk2Zr4c1F5YVg1xlpSzsEOZ8+pIDakPIYQIZeWuhhd0657qzmrOZT5UEgknIn5iM/ X-Received: by 2002:a17:906:5c43:: with SMTP id c3mr35378748ejr.390.1605875242140; Fri, 20 Nov 2020 04:27:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605875242; cv=none; d=google.com; s=arc-20160816; b=OWobGUmrQBGV7JIR5L+7sxhboZC+ARornqKmtw9GTt6mYkZ1FqdKpsi2mLmuouajHt 0VIozihhxQ7wmrFoGgceI3CWD4gUFqV+/l1uZ5Jt59ePBFh2SHKbmhHsGXJQbAJq+ITf 3LdEBPt1K+UXrgSYGjQyyPoYnZ/9aDUGjTitiKIBVqOf7m+XrOKLf/KTo7lciln5UUmb iPWG0m9I6PgTwh1eoJ+D5SD0uRXIqGmw9h7D32Ac/0IC2UjndSIYrqPgf/+gdDwbK5Li 0/EOhRrvENK/EBM/7xnXiI7Asf+ph6ZEoPYZ3dooT/KAHV/uDv7lqiCzgdW+v0mj23Ty ovmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:date:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version; bh=sjH8GVrino47ODv9g+lDP6HID/f8/yXv/zPk4avRH2U=; b=H0zrI8qojoId+rU7HqHhB5xr+UU5VUltP7IFFJhu5SPol4RQzhdQhwk3IXIJf2yZYi RWtjZpru1NCVhMJxLkgVhbaDPMrphLU6nEzeHj/HrorSG079P1PE/a15YqTcGAVM3Z5j OV9/YH17YAAJIcEFiFO0vXcrPzAzWYtoh6rrSLPc8ge7rDbMd3lyLeXB/7Qv9P8zE7bl EpSmuu99OvUnl2kPTr0CvdVxL6JQXpV2lHqnyiItkp573X9LaZqb5sf/v644EZbpWAv2 qKzpnjFBPhgigmp/Hfh9ZcSGH5inxPOaZQUQ+GjllQJiFuJIiU5ZWiZ0cbYMXQKa5940 HFnA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lz1si302630ejb.205.2020.11.20.04.26.58; Fri, 20 Nov 2020 04:27:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727766AbgKTMYc convert rfc822-to-8bit (ORCPT + 99 others); Fri, 20 Nov 2020 07:24:32 -0500 Received: from mail.fireflyinternet.com ([77.68.26.236]:54613 "EHLO fireflyinternet.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727518AbgKTMYb (ORCPT ); Fri, 20 Nov 2020 07:24:31 -0500 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 23054655-1500050 for multiple; Fri, 20 Nov 2020 12:24:02 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT In-Reply-To: <20201120101719.3172693-1-baolu.lu@linux.intel.com> References: <20201120101719.3172693-1-baolu.lu@linux.intel.com> Subject: Re: [PATCH v5 0/7] Convert the intel iommu driver to the dma-iommu api From: Chris Wilson Cc: Ashok Raj , Tvrtko Ursulin , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Lu Baolu To: Christoph Hellwig , David Woodhouse , Joerg Roedel , Lu Baolu , Tom Murphy , Will Deacon Date: Fri, 20 Nov 2020 12:24:01 +0000 Message-ID: <160587504147.19364.17448380121292539865@build.alporthouse.com> User-Agent: alot/0.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Lu Baolu (2020-11-20 10:17:12) > Lu Baolu (3): > iommu: Add quirk for Intel graphic devices in map_sg > iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev > iommu/vt-d: Cleanup after converting to dma-iommu ops > > Tom Murphy (4): > iommu: Handle freelists when using deferred flushing in iommu drivers > iommu: Add iommu_dma_free_cpu_cached_iovas() > iommu: Allow the dma-iommu api to use bounce buffers > iommu/vt-d: Convert intel iommu driver to the iommu ops Something that may be of interest is that we encounter problems with using intel-iommu across a PCI remove event. All HW generations fail with faults like: DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Write] Request device [00:02.0] PASID ffffffff fault addr 4b822000 [fault reason 02] Present bit in context entry is clear i.e. they all report missing present bit after re-adding the device to the iommu group. Forcing an identity map (or disabling iommu) works fine. I applied this series just on the off-chance it changed the symptoms; it does not. If you have any ideas on how to chase down this fault, that would be very useful. We have a few other DMAR faults visible on many platforms, all "[fault reason 07] Next page table ptr is invalid" that are again not affected by this series, that we also need to resolve. -Chris