Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp917995ybv; Thu, 20 Feb 2020 09:33:17 -0800 (PST) X-Google-Smtp-Source: APXvYqyKe6BWMSf+JMNX+gjwQfdZTKBVs+71GOwlFk7PVWadYD03utDbSXW8nqsNDR9hqFK9XKT/ X-Received: by 2002:aca:2419:: with SMTP id n25mr2914985oic.13.1582219996972; Thu, 20 Feb 2020 09:33:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582219996; cv=none; d=google.com; s=arc-20160816; b=PxUMnEy1BJmPIz9Sq1nDg293eSljs5AV55AwNBUFCvDEmuzomd4H9wpjQ1lhY6Mu8Q lpzsro6VSjvp1EdfCOTFgS5KdEfPBeNBFon56+onm/ScEC9/PIw+gpwkvyfr/SUOBF8+ 6FMWFlomkkRbYYdXDIWdAXPEFyGaVx0OjSq64W5PI+AnsQtl4pA5FwnDeB0S/aA2V3Xy jGOmgACrzV7rMyzB+2RCoU2X9BDtXDZU7YAA1KNGx7Zt7nem2zlUye8bKyTzlbowxFht VYZ5O1FHZmS4AZ/uDji3dZ7AHbYcqq5LN6qeSljA068D0nBiBJwDFsRCQ38NknECSyDK VKuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :reply-to:message-id:subject:to:from:date:dkim-signature; bh=qhtQcGBTl4nwp8gN4Hlxs7R2XI/3YERGs+eAbVjqzyU=; b=EbFCrazjxQlkqgUWtqiNyiUUNSegjo44qI+Vo+vPsfh8M+fJfS0+DBdNnGTwsC7BY6 lyFmBKY6I6rqzgSHn7pkqxIPMJKVoVuUV8akKZvg/1ZQOHPiRLF+QyeYZswAAWyf7reo cPCa3aWAZGU2+tOLrNS6dF8mJsVWqVpvoO7sUw4nVEGDaIUtPEVai0Ci5c69HneVE+K9 Qyol8msdkxFTxwmBwortbBHr1eKzQbnmtZsgR35Y1ZHjTQgvgi7r+lVhTpX4mxgkpZuR TlEtJexSt9fLHDZ3K5pBjbSG2h5vLz2//wTMFmBi1JjIw+2omRFumJ1v/sKy0+KOot9S RRsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HNepBQpK; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n2si37553otk.177.2020.02.20.09.33.00; Thu, 20 Feb 2020 09:33:16 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HNepBQpK; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728685AbgBTRcX (ORCPT + 99 others); Thu, 20 Feb 2020 12:32:23 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:42972 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726959AbgBTRcX (ORCPT ); Thu, 20 Feb 2020 12:32:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582219942; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qhtQcGBTl4nwp8gN4Hlxs7R2XI/3YERGs+eAbVjqzyU=; b=HNepBQpK5p5wD9t8EY45sY1m5BeVZiQFgsJaIAia+jtlFLB5hgwxL6PLpwKkP2hRmAcvkj BuTqK1RS4k1tCtgyptTCIK8DDwRwC4FQrZnnmnSBUX25ROk5iEKU+IzN+N8JmSTJLC2auk Pb6S0E3J/+TFhv8cw6LsmE0ntYP3lsE= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-352-C4v2X6LRPTO6ofN5xEULvA-1; Thu, 20 Feb 2020 12:32:16 -0500 X-MC-Unique: C4v2X6LRPTO6ofN5xEULvA-1 Received: by mail-qv1-f69.google.com with SMTP id c1so3043783qvw.17 for ; Thu, 20 Feb 2020 09:32:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=qhtQcGBTl4nwp8gN4Hlxs7R2XI/3YERGs+eAbVjqzyU=; b=NKrQxrZPqIOJiKeozfYfo6vjkir1dM5Y5q8UPiuDLl9KZ/thMZGkCHaGTC2mL+XU3u 61J9rz6dsTvJvZ/lbqZf6+fYZS8VsAnO7qwxLGIDbU78GC7XyHFUxinEodDbpA2p4gfD sH1/0AT35k5e2hOqMld1dkOSQ1hIQns66B69/ozrfhs+AsxXJqqgEtTlaBNGddg2od4k NgS+xBXMw7l39bcZLhSYvA89xHw8nYGve7GFNy1dfZkXio8GkBDlTIahnrxnBMT+bGcT nlfLswCG+dg9nXAvbJBzvWTVv4Nxhhb2dq3fc52+AYEVTbUzl2Jjm11Ci2BgIBEqxBq6 +VkQ== X-Gm-Message-State: APjAAAXMptHXlfH7pyPumRkGQSA0naJOfWXe0SynKwNIKi+ZzuPrcrgX HFNhGLWkTKj4vqm1bjsORQREt7QHJl4iElpy/KUPA5Yr2pMbsBrhiXZNYEOJODLjNlF+jEa3CB6 ZehVpyVjbpwZ3ecisR4vKSkkm X-Received: by 2002:ae9:c318:: with SMTP id n24mr30412679qkg.38.1582219936268; Thu, 20 Feb 2020 09:32:16 -0800 (PST) X-Received: by 2002:ae9:c318:: with SMTP id n24mr30412640qkg.38.1582219935836; Thu, 20 Feb 2020 09:32:15 -0800 (PST) Received: from localhost (ip70-163-223-149.ph.ph.cox.net. [70.163.223.149]) by smtp.gmail.com with ESMTPSA id t187sm118485qke.85.2020.02.20.09.32.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 09:32:15 -0800 (PST) Date: Thu, 20 Feb 2020 10:32:13 -0700 From: Jerry Snitselaar To: Lu Baolu , Joerg Roedel , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: question about iommu_need_mapping Message-ID: <20200220173213.moynvygrdzc66zqg@cantor> Reply-To: Jerry Snitselaar Mail-Followup-To: Lu Baolu , Joerg Roedel , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org References: <20200219235516.zl44y7ydgqqja6x5@cantor> <20200220162441.bhnpwgsmj4vlp3ve@cantor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200220162441.bhnpwgsmj4vlp3ve@cantor> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu Feb 20 20, Jerry Snitselaar wrote: >On Thu Feb 20 20, Lu Baolu wrote: >>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 > >Hi Baolu, > >Would this mean switching to bounce_dma_ops instead? > Never mind. I see that it would go into the dma_direct code. >Regards, >Jerry > >>_______________________________________________ >>iommu mailing list >>iommu@lists.linux-foundation.org >>https://lists.linuxfoundation.org/mailman/listinfo/iommu