From: Christoph Hellwig <hch@infradead.org>
To: Tom Murphy <murphyt7@tcd.ie>
Cc: iommu@lists.linux-foundation.org,
Heiko Stuebner <heiko@sntech.de>,
virtualization@lists.linux-foundation.org,
linux-tegra@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
Will Deacon <will@kernel.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
linux-samsung-soc@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-rockchip@lists.infradead.org,
Andy Gross <agross@kernel.org>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
linux-s390@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
linux-kernel@vger.kernel.org, Kukjin Kim <kgene@kernel.org>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH V5 1/5] iommu/amd: Remove unnecessary locking from AMD iommu driver
Date: Tue, 20 Aug 2019 02:41:43 -0700 [thread overview]
Message-ID: <20190820094143.GA24154@infradead.org> (raw)
In-Reply-To: <20190815110944.3579-2-murphyt7@tcd.ie>
On Thu, Aug 15, 2019 at 12:09:39PM +0100, Tom Murphy wrote:
> We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap.
> iommu_map doesn’t lock while mapping and so no two calls should touch
> the same iova range. The AMD driver already handles the page table page
> allocations without locks so we can safely remove the locks.
I've been looking over the code and trying to understand how the
synchronization works. I gues we the cmpxchg64 in free_clear_pte
is the important point here? I have to admit I don't fully understand
the concurrency issues here, but neither do I understand what the
mutex you removed might have helped to start with.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Tom Murphy <murphyt7@tcd.ie>
Cc: Heiko Stuebner <heiko@sntech.de>,
virtualization@lists.linux-foundation.org,
Matthias Brugger <matthias.bgg@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>,
Will Deacon <will@kernel.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
linux-samsung-soc@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-rockchip@lists.infradead.org, Kukjin Kim <kgene@kernel.org>,
Andy Gross <agross@kernel.org>,
linux-s390@vger.kernel.org,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH V5 1/5] iommu/amd: Remove unnecessary locking from AMD iommu driver
Date: Tue, 20 Aug 2019 02:41:43 -0700 [thread overview]
Message-ID: <20190820094143.GA24154@infradead.org> (raw)
In-Reply-To: <20190815110944.3579-2-murphyt7@tcd.ie>
On Thu, Aug 15, 2019 at 12:09:39PM +0100, Tom Murphy wrote:
> We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap.
> iommu_map doesn’t lock while mapping and so no two calls should touch
> the same iova range. The AMD driver already handles the page table page
> allocations without locks so we can safely remove the locks.
I've been looking over the code and trying to understand how the
synchronization works. I gues we the cmpxchg64 in free_clear_pte
is the important point here? I have to admit I don't fully understand
the concurrency issues here, but neither do I understand what the
mutex you removed might have helped to start with.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Tom Murphy <murphyt7@tcd.ie>
Cc: iommu@lists.linux-foundation.org,
Heiko Stuebner <heiko@sntech.de>,
virtualization@lists.linux-foundation.org,
linux-tegra@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
Will Deacon <will@kernel.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
linux-samsung-soc@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-rockchip@lists.infradead.org,
Andy Gross <agross@kernel.org>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
linux-s390@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
linux-kernel@vger.kernel.org, Kukjin Kim <kgene@kernel.org>
Subject: Re: [PATCH V5 1/5] iommu/amd: Remove unnecessary locking from AMD iommu driver
Date: Tue, 20 Aug 2019 02:41:43 -0700 [thread overview]
Message-ID: <20190820094143.GA24154@infradead.org> (raw)
In-Reply-To: <20190815110944.3579-2-murphyt7@tcd.ie>
On Thu, Aug 15, 2019 at 12:09:39PM +0100, Tom Murphy wrote:
> We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap.
> iommu_map doesn’t lock while mapping and so no two calls should touch
> the same iova range. The AMD driver already handles the page table page
> allocations without locks so we can safely remove the locks.
I've been looking over the code and trying to understand how the
synchronization works. I gues we the cmpxchg64 in free_clear_pte
is the important point here? I have to admit I don't fully understand
the concurrency issues here, but neither do I understand what the
mutex you removed might have helped to start with.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Tom Murphy <murphyt7@tcd.ie>
Cc: Heiko Stuebner <heiko@sntech.de>,
virtualization@lists.linux-foundation.org,
Matthias Brugger <matthias.bgg@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>,
Will Deacon <will@kernel.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
linux-samsung-soc@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-rockchip@lists.infradead.org, Kukjin Kim <kgene@kernel.org>,
Andy Gross <agross@kernel.org>,
linux-s390@vger.kernel.org,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH V5 1/5] iommu/amd: Remove unnecessary locking from AMD iommu driver
Date: Tue, 20 Aug 2019 02:41:43 -0700 [thread overview]
Message-ID: <20190820094143.GA24154@infradead.org> (raw)
In-Reply-To: <20190815110944.3579-2-murphyt7@tcd.ie>
On Thu, Aug 15, 2019 at 12:09:39PM +0100, Tom Murphy wrote:
> We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap.
> iommu_map doesn’t lock while mapping and so no two calls should touch
> the same iova range. The AMD driver already handles the page table page
> allocations without locks so we can safely remove the locks.
I've been looking over the code and trying to understand how the
synchronization works. I gues we the cmpxchg64 in free_clear_pte
is the important point here? I have to admit I don't fully understand
the concurrency issues here, but neither do I understand what the
mutex you removed might have helped to start with.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-20 9:41 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 11:09 [PATCH V5 0/5] iommu/amd: Convert the AMD iommu driver to the dma-iommu api Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` [PATCH V5 1/5] iommu/amd: Remove unnecessary locking from AMD iommu driver Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-20 9:41 ` Christoph Hellwig [this message]
2019-08-20 9:41 ` Christoph Hellwig
2019-08-20 9:41 ` Christoph Hellwig
2019-08-20 9:41 ` Christoph Hellwig
2019-08-24 7:56 ` Tom Murphy
2019-08-24 7:56 ` Tom Murphy
2019-08-24 7:56 ` Tom Murphy
2019-08-24 7:56 ` Tom Murphy
2019-08-24 22:41 ` Christoph Hellwig
2019-08-24 22:41 ` Christoph Hellwig
2019-08-24 22:41 ` Christoph Hellwig
2019-08-24 22:41 ` Christoph Hellwig
2019-08-24 22:41 ` Christoph Hellwig
2019-08-24 7:56 ` Tom Murphy
2019-08-20 9:41 ` Christoph Hellwig
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` [PATCH V5 2/5] iommu: Add gfp parameter to iommu_ops::map Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-19 18:23 ` Robin Murphy
2019-08-19 18:23 ` Robin Murphy
2019-08-19 18:23 ` Robin Murphy
2019-08-19 18:23 ` Robin Murphy
2019-08-19 18:23 ` Robin Murphy
2019-08-20 9:41 ` Christoph Hellwig
2019-08-20 9:41 ` Christoph Hellwig
2019-08-20 9:41 ` Christoph Hellwig
2019-08-20 9:41 ` Christoph Hellwig
2019-08-20 9:41 ` Christoph Hellwig
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` [PATCH V5 3/5] iommu/dma-iommu: Handle deferred devices Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-19 18:26 ` Robin Murphy
2019-08-19 18:26 ` Robin Murphy
2019-08-19 18:26 ` Robin Murphy
2019-08-19 18:26 ` Robin Murphy
2019-08-19 18:26 ` Robin Murphy
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-15 11:09 ` [PATCH V5 4/5] iommu/dma-iommu: Use the dev->coherent_dma_mask Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-19 18:39 ` Robin Murphy
2019-08-19 18:39 ` Robin Murphy
2019-08-19 18:39 ` Robin Murphy
2019-08-19 18:39 ` Robin Murphy
2019-08-19 18:39 ` Robin Murphy
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-20 9:43 ` Christoph Hellwig
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` [PATCH V5 5/5] iommu/amd: Convert AMD iommu driver to the dma-iommu api Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-15 11:09 ` Tom Murphy
2019-08-17 3:39 ` [PATCH V5 3/5] iommu/dma-iommu: Handle deferred devices Hillf Danton
2019-08-17 3:39 ` Hillf Danton
2019-08-17 3:39 ` Hillf Danton
2019-08-17 7:19 ` Tom Murphy
2019-08-17 7:19 ` Tom Murphy
2019-08-17 7:19 ` Tom Murphy
2019-08-17 7:19 ` Tom Murphy
2019-08-17 7:19 ` Tom Murphy
2019-09-05 6:18 ` [PATCH V5 0/5] iommu/amd: Convert the AMD iommu driver to the dma-iommu api Christoph Hellwig
2019-09-05 6:18 ` Christoph Hellwig
2019-09-05 6:18 ` Christoph Hellwig
2019-09-05 6:18 ` Christoph Hellwig
2019-09-05 6:18 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190820094143.GA24154@infradead.org \
--to=hch@infradead.org \
--cc=agross@kernel.org \
--cc=dwmw2@infradead.org \
--cc=gerald.schaefer@de.ibm.com \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=jonathanh@nvidia.com \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=murphyt7@tcd.ie \
--cc=robin.murphy@arm.com \
--cc=thierry.reding@gmail.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.