Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp172246ybv; Wed, 19 Feb 2020 18:50:31 -0800 (PST) X-Google-Smtp-Source: APXvYqzHNx1f3FQzloGGTzq36CIYSCRI3dVwFm27BdozvUeoU6IXh/uBDhjv3ouWkIjAF7L9MRZo X-Received: by 2002:aca:5106:: with SMTP id f6mr555137oib.112.1582167031234; Wed, 19 Feb 2020 18:50:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582167031; cv=none; d=google.com; s=arc-20160816; b=SoDHOLo38+4RSCQite0hbIWcDGzdAV55SZXcqkeetLq5MLSPK1Rb/AvLjypPXs/F2U dUIrgKd/uJFnqK8G7cKjS0nbIy+M0lbzDnA5UVEosSmfZyXPBwHBtQV1Gxo545uVGFls jMHAe9oYJv2BEc+QHKl1FjY9sFpv5KUVjprVlzgW4/36GuVYkFW2E/jx3rbGF+pZM4iW iVjfZyvZQsbJWqUj3l+fYeSL73zMEj3Qjawt5011oF9k6G7Tcx5K+JXVxBCIi2D4gdkm Gfm8W6OWnAJhGwoGaRMzaX8//Emo2XWy69xF19yReR/QyPew1c/hxTYy9cgQ8gO5QpDF fQLg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=ZAmWpYxtPPw9vPV3/83T6xOv/6IiQFXsYYVUuK7Tiqc=; b=dWhLuFHoVwbLTZR0SQ0D9IXEH8nggLau78mZ7AZjmsTHmmzNwCquAD2efTNAjVFo0a uPTMDShqjhopsjDkhEI13Sl+Ua7FA7yIHbD5u4OW/igB627TsjrkdzAv1Vrjr6gpZCo0 VQls2ViVcfgPh36G2MjUycaU/ftHVOxagk0DPm02s3SVwuKL+7zEX0ghio3xnGtPk8Pw 2GdOXSF7vrZVREsa9fuIQR25/OAuta99/q20ftAsLZwKbscpWanJTuohrwHCIaaIpK3U En9r8mb+VpkGuLl+tx74jOINqd0omFo7xFro6wRBUU8lj/oerZKhIM6rIi5RcbqvEmJS 6IaA== 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 t3si10714043oig.25.2020.02.19.18.50.18; Wed, 19 Feb 2020 18:50:31 -0800 (PST) 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 S1727756AbgBTCtm (ORCPT + 99 others); Wed, 19 Feb 2020 21:49:42 -0500 Received: from mga09.intel.com ([134.134.136.24]:43079 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727211AbgBTCtm (ORCPT ); Wed, 19 Feb 2020 21:49:42 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2020 18:49:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,462,1574150400"; d="scan'208";a="228782315" Received: from blu2-mobl3.ccr.corp.intel.com (HELO [10.249.162.231]) ([10.249.162.231]) by fmsmga007.fm.intel.com with ESMTP; 19 Feb 2020 18:49:39 -0800 Subject: Re: question about iommu_need_mapping To: Joerg Roedel , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org References: <20200219235516.zl44y7ydgqqja6x5@cantor> From: Lu Baolu Message-ID: Date: Thu, 20 Feb 2020 10:49:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200219235516.zl44y7ydgqqja6x5@cantor> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jerry, On 2020/2/20 7:55, Jerry Snitselaar wrote: > Is it possible for a device to end up with dev->archdata.iommu == NULL > on iommu_need_mapping in the following instance: > > 1. iommu_group has dma domain for default > 2. device gets private identity domain in intel_iommu_add_device > 3. iommu_need_mapping gets called with that device. > 4. dmar_remove_one_dev_info sets dev->archdata.iommu = NULL via > unlink_domain_info. > 5. request_default_domain_for_dev exits after checking that > group->default_domain >    exists, and group->default_domain->type is dma. > 6. iommu_request_dma_domain_for_dev returns 0 from > request_default_domain_for_dev >    and a private dma domain isn't created for the device. > Yes. It's possible. > The case I was seeing went away with commit 9235cb13d7d1 ("iommu/vt-d: > Allow devices with RMRRs to use identity domain"), because it changed > which domain the group and devices were using, but it seems like it is > still a possibility with the code. Baolu, you mentioned possibly > removing the domain switch. Commit 98b2fffb5e27 ("iommu/vt-d: Handle > 32bit device with identity default domain") makes it sound like the > domain switch is required. It's more "nice to have" than "required" if the iommu driver doesn't disable swiotlb explicitly. The device access of system memory higher than the device's addressing capability could go through the bounced buffer implemented in swiotlb. Best regards, baolu