Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1224866imu; Wed, 16 Jan 2019 15:09:54 -0800 (PST) X-Google-Smtp-Source: ALg8bN5GpohAgMXyCIMCYAD8Gl5ebm9DzyJdeEo03no56s7nOlQ3r/uHpxUwElwZIDe/6PUwWJFc X-Received: by 2002:a62:32c4:: with SMTP id y187mr12710944pfy.195.1547680194080; Wed, 16 Jan 2019 15:09:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547680194; cv=none; d=google.com; s=arc-20160816; b=l6c0VEpbWKmUxMBwqwSm60P+k0yh8Fghp5qGbeCtDBctJwe6AYG3WitHEI+fupod+e 5Z4BB+wi7QxA4PQ+zL12pCb9rWI8DJ6vP6BqA5Dxv3qC6tBHhxuY11s1wztwcW9rlP+j nMjAk4A5jGIGqAbA/A7UFea73VkQ7+AplSFlxc5AArpRV2uPR+EZfi1NCv/pZUFEJ6Ma w1Xs1Sbf7DPzOHvqBVs3dmp6mIAsr9NweHrAGI7cP/Nz9KUuucTKmKaYpQvwI7b/MhXL NabHwGeN1plbWlB0TGxPeGLlvkN5ObpsdfhPrSGaGwbj79TAzDXfDBxWmnj+HVom8htb HaCw== 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=GtK+8iA4ap2qvPIUoBCvghj7nEhpJM1j39GsT3fL1ho=; b=XnAUqhzNa47KwsXdjdWdQNGsXirbFTYjvGLEID4CQIhVkN0LY/8oyFUcBCVOh2wDi+ PGun4aXc2IaOONL+Y9lwz99RawejR59NPSiujPKWGAs8mnIUM8UrhkLURB+dbrUXvBok 37egKXlolUUC7d9Hlif7yhtDp997NWfvoSs0t1CSuVYdiwe9t3wCXU5wxEY7JzQyIGqm ky5HZHnrIrzsrMgcHBfAFNeB62DPCwg1zkJFw5iLm5ouNO1jGw5nFeBNa1zLt9kUlVit C76XUsijVTD0Im5hWEFHzXdBezPg5Yyu3xAH/4ZA5x9uWC9S1AP8GhHGRD/a8duqsuKh eZfQ== 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 f186si7893853pfb.67.2019.01.16.15.09.38; Wed, 16 Jan 2019 15:09:54 -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 S2394400AbfAPRIy (ORCPT + 99 others); Wed, 16 Jan 2019 12:08:54 -0500 Received: from 8bytes.org ([81.169.241.247]:58030 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731892AbfAPRIy (ORCPT ); Wed, 16 Jan 2019 12:08:54 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id EDF57396; Wed, 16 Jan 2019 18:08:52 +0100 (CET) Date: Wed, 16 Jan 2019 18:08:52 +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: <20190116170852.GD4681@8bytes.org> References: <20190116041546.3541-1-Suravee.Suthikulpanit@amd.com> <20190116132648.i5n3hz3k7d2wxbrx@8bytes.org> <60c24182-c58e-0575-b085-c7eebc00c49b@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60c24182-c58e-0575-b085-c7eebc00c49b@amd.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 16, 2019 at 02:08:55PM +0000, Suthikulpanit, Suravee wrote: > Actually, I am not sure how we would be missing the flush on the last device. > In my test, I am seeing the flush command being issued correctly during > vfio_unmap_unpin(), which is after all devices are detached. > Although, I might be missing your point here. Could you please elaborate? Okay, you are right, the patch effectivly adds an unconditional flush of the domain on all iommus when the last device is detached. So it is correct in that regard. But that code path is also used in the iommu_unmap() path. The problem now is, that with your change we send flush commands to all IOMMUs in the unmap path when no device is attached to the domain. This will hurt performance there, no? Regards, Joerg