Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp853094ybv; Thu, 20 Feb 2020 08:25:24 -0800 (PST) X-Google-Smtp-Source: APXvYqxmtD9DY+izdW/J8YuxkDIY1rvsfP4Ri7UDBr1RQOWk9BCBRc/nWiy3D49dX6nLn7AIZAxa X-Received: by 2002:a9d:7489:: with SMTP id t9mr23609976otk.255.1582215924816; Thu, 20 Feb 2020 08:25:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582215924; cv=none; d=google.com; s=arc-20160816; b=QUNSqEKXfLBNFXipltjmW+dYh8R6DU2Uzg3flMpNpa5T43m0VQ2oBHox85e7c+Wwh7 JZa1E9GTcCcELcVWWQWigncIf7w6zb5rkrZcdV9/ej4ZqbpdA0HU1YYOTFick/xYE3c0 iILu5mbSQltLhY+GbBHKkWbNerOvwkWwKd5AWu7XPYlOnC4SezbMDojuh3MdQyB98tDk tdHkZVFoZ5WMk0ZL+xGwbjhUVv3WUwUDoTthXgoi6Gl6MD8VuKMvKj+WGpPfDOzqMK/r yKd5v6+2nPq53dwblW/yLL/sGR1u6Jo6gyy7mYFYPZ9HhtXGQmGHdzB4ueYCA5FduHTu 5dVw== 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:cc:to:from:date:dkim-signature; bh=EFDhWGMMz3c3KINy5m2oRHAjI8OMHRzcdj6Y8N7UCZs=; b=y7Aa58qHJhX8y99PjiWsPu6J54vbUUO+hseGIXXd3ZDEVe1OUZ50ejuwsmNQ4Ccub4 HuCwhlroMpScrmcg7SRAA3q/JXBADgr/eulQHXSRyAvPDzLbQukUZUJwNhaLGVdJMNm1 uGzpXLsrtUmN+ztLB0nTmrSeuMCpjrUh6rxrhCMej9XcP8BBhExfBjXc8DCWyzx6TBGu vFfj5PAqL/yt6UzOe49pS68FhaKzUn6ttMMg5zxKE2RhU/DSaWtarPG+oTId6zDbe7AC /7U3rePNLGON5n5pH9YSQOlKYGaicdZEjSG7B6PzeN0vU9SL8RxDKGLL6oikoHXgmFO4 c6HA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZaT0m8MZ; 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 i78si11875211oib.1.2020.02.20.08.25.12; Thu, 20 Feb 2020 08:25:24 -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=ZaT0m8MZ; 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 S1728237AbgBTQYw (ORCPT + 99 others); Thu, 20 Feb 2020 11:24:52 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:25041 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727709AbgBTQYv (ORCPT ); Thu, 20 Feb 2020 11:24:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582215891; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EFDhWGMMz3c3KINy5m2oRHAjI8OMHRzcdj6Y8N7UCZs=; b=ZaT0m8MZyX0LhG7vejdTQjhegHzXC0+/T99ErcHZmxzb6Q8SGVlL4sy57GfSmZ0yn5Pclf Cb98N0k0dLD3iTohrjs3gv3uXX1ENb1Te+MJ08XYguBIX6yqZcvTYFFMuF/ItEdJCh04DT 5WYuEp/cFmbxx9S40KHRmIpRn8eAvEk= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-54-Br-T_tzhNCSqfCSYaWyiyg-1; Thu, 20 Feb 2020 11:24:44 -0500 X-MC-Unique: Br-T_tzhNCSqfCSYaWyiyg-1 Received: by mail-qt1-f199.google.com with SMTP id l25so2965087qtu.0 for ; Thu, 20 Feb 2020 08:24:44 -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:cc:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=EFDhWGMMz3c3KINy5m2oRHAjI8OMHRzcdj6Y8N7UCZs=; b=nwv9GAubCg3t3jnUDaYX4gSJNd4G0ZpIsC0ZBMOqi/Zeg5KkBtlOBQmUmtUMw5ke8H laxhuzov9tlU3d4hGkyd79GEKn2V6PSQfOJbLgFcVOmr/wd1k8NPOmGO0sv3wKADaxlD ifrA4wmc1dCbUDrfLKY39mBuUVkKynNLjbxl6+Qeh78uJVzCe5uhynWWWkdGJ4TP6+je GyZ8HYoRsWGF5h0q37MdfAmygfLhBkV6vHNknSjtVx323DS3u5ogX3q3m2jjhrofixFj WC+gO2fwcmFAWQQXpJos7ikG5Xs1qvWJ1GpEhD8miZ15yapQJBCYd/9PnBHOvBAtkdrM qd4g== X-Gm-Message-State: APjAAAVnAM+na6exMZIQ5+SFSwFo3Ipg4I0BrxxGv1pI52jFDBpE3MO/ Sjg/gOe4iyUeA1wWlxUvevAniq2BEJNn3dDiAR+0RFu0YNKr1N42hCLghJ87aHzhHpTCMj2ydo8 mlKOw0NV35el5fg7bm3u1e8Q2 X-Received: by 2002:ac8:694f:: with SMTP id n15mr27477729qtr.372.1582215883457; Thu, 20 Feb 2020 08:24:43 -0800 (PST) X-Received: by 2002:ac8:694f:: with SMTP id n15mr27477689qtr.372.1582215883126; Thu, 20 Feb 2020 08:24:43 -0800 (PST) Received: from localhost (ip70-163-223-149.ph.ph.cox.net. [70.163.223.149]) by smtp.gmail.com with ESMTPSA id l25sm8111qkk.115.2020.02.20.08.24.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 08:24:42 -0800 (PST) Date: Thu, 20 Feb 2020 09:24:41 -0700 From: Jerry Snitselaar To: Lu Baolu Cc: Joerg Roedel , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: question about iommu_need_mapping Message-ID: <20200220162441.bhnpwgsmj4vlp3ve@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Regards, Jerry >_______________________________________________ >iommu mailing list >iommu@lists.linux-foundation.org >https://lists.linuxfoundation.org/mailman/listinfo/iommu