Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1306406ybl; Thu, 22 Aug 2019 12:24:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqx5QlCGjcbtDo4eDbYa846comMja2RcnJvctv/BSJhHoxHQE8v85BH90ICQG4c1aco+hnxh X-Received: by 2002:a17:90a:fd8c:: with SMTP id cx12mr1281794pjb.95.1566501875401; Thu, 22 Aug 2019 12:24:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566501875; cv=none; d=google.com; s=arc-20160816; b=mtdga8O1zpxOxYkLwYt6LL4AteNZoVTRw5wmZgUnKMyCsoDx10A5buCyyJRF1v8j0n mq5YJFKJ5PM6SW91MA6kbeKCBEmgunTVEsqOJ9pcfkkGza5yoB6uxrBPQxbiKlWAHEix z9P7TsrPTbG9+j9C2XLkzCqWOCnAQskyT5ILHPEud5t6oP7sdmXdqYxxJu1G9ANUGIGv 1dKS+nn/LMW0UMjfLV5Z3R0NKWbr8hRfSLrPlm5+35Zj5OdAPH90SiH8WWVkNDQZWYE+ 3/NWVuTW/W0uPMDUmTmd7isreHjfG1uysgYrjhSXyTdQK8qq2RcSuVnTHU3fpFEacsBV K8VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=o4PDvs24NGrbefG7Sx4dU0/E8z5s/YEZs0volGW1WpI=; b=Bt5xCg7H6YkuQbMBbQHLcZQyNNtwmwfBRrVsdnVQYfshzsHgB6uXSgzCbjpRRHdFwo i1OZTtvJ+meuzgCMD7sBfonbC+GzeDgx5hJFmQ2VnEOkbpKv+EeAgk6Ymw6mAoDXUknM e1474SS8FWsOiuYKLYg9HMWTGcds/rAe5LesDmCe+/q70rv4BFyopeG0AqKPgQ9LOXzh MLejRwQSWS4Gru4Kc8YSI9mPgJ0z9gUBDJv44BlAd0AHo8Z/wFVgeNN2vIvLfsmSoCVx HOijPnusMeG6Tcq9LxZBXN1p1Evp02YyjZ+4NldwpTW/r6Zrw+fyLHWLTTZtPtR5T8c1 /arA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k142si430714pfd.217.2019.08.22.12.24.20; Thu, 22 Aug 2019 12:24:35 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732836AbfHVO3t (ORCPT + 99 others); Thu, 22 Aug 2019 10:29:49 -0400 Received: from mga17.intel.com ([192.55.52.151]:30737 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732001AbfHVO3t (ORCPT ); Thu, 22 Aug 2019 10:29:49 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2019 07:29:49 -0700 X-IronPort-AV: E=Sophos;i="5.64,417,1559545200"; d="scan'208";a="178873789" Received: from jkrzyszt-desk.igk.intel.com ([172.22.244.17]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2019 07:29:47 -0700 From: Janusz Krzysztofik To: David Woodhouse , Joerg Roedel Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, =?UTF-8?q?Micha=C5=82=20Wajdeczko?= , Janusz Krzysztofik Subject: [RFC PATCH] iommu/vt-d: Fix IOMMU field not populated on device hot re-plug Date: Thu, 22 Aug 2019 16:29:22 +0200 Message-Id: <20190822142922.31526-1-janusz.krzysztofik@linux.intel.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a perfectly working i915 device is hot unplugged (via sysfs) and hot re-plugged again, its dev->archdata.iommu field is not populated again with an IOMMU pointer. As a result, the device probe fails on DMA mapping error during scratch page setup. It looks like that happens because devices are not detached from their MMUIO bus before they are removed on device unplug. Then, when an already registered device/IOMMU association is identified by the reinstantiated device's bus and function IDs on IOMMU bus re-attach attempt, the device's archdata is not populated with IOMMU information and the bad happens. I'm not sure if this is a proper fix but it works for me so at least it confirms correctness of my analysis results, I believe. So far I haven't been able to identify a good place where the possibly missing IOMMU bus detach on device unplug operation could be added. Signed-off-by: Janusz Krzysztofik --- drivers/iommu/intel-iommu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 12d094d08c0a..7cdcd0595408 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -2477,6 +2477,9 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu, if (info2) { found = info2->domain; info2->dev = dev; + + if (dev && !dev->archdata.iommu) + dev->archdata.iommu = info2; } } -- 2.21.0