Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7241134imu; Tue, 22 Jan 2019 02:46:26 -0800 (PST) X-Google-Smtp-Source: ALg8bN5eS+lqi8mKeIrFKFDCYNv4DJS9dG2kY7VL8xfBAo8hqQ6xazXNw7S9DpLBJ53wcQOM2rM5 X-Received: by 2002:a62:1d8f:: with SMTP id d137mr32723480pfd.11.1548153986037; Tue, 22 Jan 2019 02:46:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548153985; cv=none; d=google.com; s=arc-20160816; b=ZtB8VvpC5kEiTEbCXZ0L7HCFTfZwYMR7SZjaIfmGQKlIJylAuIbZHOxd7obkmzQVL9 51M46t0UoL4sjlSJZNKRz9V72tXa2x+x8BXKPy/iR9edYcvBeJ1DUGjl4rniysWqB4+U CjKi6U1w9SX748YT2AlfdeJjFDjsnkhjz6aDaOakZFF73jXqd/EgqCKS0vZVy4NAAx5l PFQ/63bP9E+i05AkTUjnZx6LdZJLfAeKHrQvNvYYsClloJDYSeehdBe0kYN7aRhIFQ2n VUUmYJU0TbaUEre1V5rL0hdmToD+/ua0xfKOjZZR+gGT1hZfGsa0TzowTp/TF9smpO1s MGFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3zsXdvUDA4ANMi4choigTJNT/nJFmwDvB/2+QQ2ds+w=; b=CpVtZMuUyOsTZxBrw+x4/l06/FmXOzUgQDh5+gvCCZf8xWZh6zMlPHTnDnMGRg2TN+ WZu2CTudZjl9Eb5PwtrrPjp0PsyBqS6tY9em2bX5lJ+FyYjyFm0TSp86DDPF9Rj3TD+c FBOOFOS8kMXPjRBPfD58QsI0ZYl9iLzZwweOBy58dxbJHjBJPIArgMQ8Mrm2Qnbb0ydP /WwPftzDWY+cRNW9FMuhOV2NB95hAkm3Gph8gD+QGx9q0b//gor1lq37IfChwllDqUaY XxE3TRWZGI9ktGyU3Z8bfJEJfhNcTORjpGBLTtaEUhzokqJUnu8nKqYV48cAOqs4Q8uG CXdw== 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=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9si15114253pfq.129.2019.01.22.02.46.10; Tue, 22 Jan 2019 02:46:25 -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=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727692AbfAVKo6 (ORCPT + 99 others); Tue, 22 Jan 2019 05:44:58 -0500 Received: from 8bytes.org ([81.169.241.247]:58774 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726530AbfAVKo6 (ORCPT ); Tue, 22 Jan 2019 05:44:58 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id 021EB672; Tue, 22 Jan 2019 11:44:55 +0100 (CET) Date: Tue, 22 Jan 2019 11:44:54 +0100 From: "joro@8bytes.org" To: "Suthikulpanit, Suravee" Cc: "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , Boris Ostrovsky , "Singh, Brijesh" Subject: Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain Message-ID: <20190122104454.nke2knuyqiswfh5w@8bytes.org> References: <20190116041546.3541-1-Suravee.Suthikulpanit@amd.com> <20190116132648.i5n3hz3k7d2wxbrx@8bytes.org> <60c24182-c58e-0575-b085-c7eebc00c49b@amd.com> <20190116170852.GD4681@8bytes.org> <0a61c07d-edfe-2738-380d-33d39e40fc0a@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a61c07d-edfe-2738-380d-33d39e40fc0a@amd.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Suravee, On Thu, Jan 17, 2019 at 08:44:36AM +0000, Suthikulpanit, Suravee wrote: > Then, in __domain_flush_pages, we issue command when the dev_iommu[] >= 0. > This should preserve previous behavior, and only add flushing condition to > the specific IOMMU in detached state. Please let me know what you think. I think the whole point why VFIO is detaching all devices first and then goes into unmapping pages is that there are no flushes needed anymore when devices are detached. But when we follow your proposal we would still do IOTLB flushes even when no devices are attached anymore. So I'd like to avoid this, given the implications on unmapping performance. We should just flush the IOMMU TLB at detach time and be done with it. Makes sense? Regards, Joerg