kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: jgg@nvidia.com, joro@8bytes.org, will@kernel.org,
	marcan@marcan.st, sven@svenpeter.dev, robdclark@gmail.com,
	m.szyprowski@samsung.com, krzysztof.kozlowski@linaro.org,
	baolu.lu@linux.intel.com, agross@kernel.org,
	bjorn.andersson@linaro.org, matthias.bgg@gmail.com,
	heiko@sntech.de, orsonzhai@gmail.com, baolin.wang7@gmail.com,
	zhang.lyra@gmail.com, wens@csie.org, jernej.skrabec@gmail.com,
	samuel@sholland.org, jean-philippe@linaro.org,
	alex.williamson@redhat.com, suravee.suthikulpanit@amd.com,
	alyssa@rosenzweig.io, alim.akhtar@samsung.com,
	dwmw2@infradead.org, yong.wu@mediatek.com,
	mjrosato@linux.ibm.com, gerald.schaefer@linux.ibm.com,
	thierry.reding@gmail.com, vdumpa@nvidia.com,
	jonathanh@nvidia.com, cohuck@redhat.com,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
	linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain
Date: Mon, 6 Jun 2022 18:50:33 +0100	[thread overview]
Message-ID: <6575de6d-94ba-c427-5b1e-967750ddff23@arm.com> (raw)
In-Reply-To: <Yp4wiJZWxoCLY8tm@Asurada-Nvidia>

On 2022-06-06 17:51, Nicolin Chen wrote:
> Hi Robin,
> 
> On Mon, Jun 06, 2022 at 03:33:42PM +0100, Robin Murphy wrote:
>> On 2022-06-06 07:19, Nicolin Chen wrote:
>>> The core code should not call an iommu driver op with a struct device
>>> parameter unless it knows that the dev_iommu_priv_get() for that struct
>>> device was setup by the same driver. Otherwise in a mixed driver system
>>> the iommu_priv could be casted to the wrong type.
>>
>> We don't have mixed-driver systems, and there are plenty more
>> significant problems than this one to solve before we can (but thanks
>> for pointing it out - I hadn't got as far as auditing the public
>> interfaces yet). Once domains are allocated via a particular device's
>> IOMMU instance in the first place, there will be ample opportunity for
>> the core to stash suitable identifying information in the domain for
>> itself. TBH even the current code could do it without needing the
>> weirdly invasive changes here.
> 
> Do you have an alternative and less invasive solution in mind?
> 
>>> Store the iommu_ops pointer in the iommu_domain and use it as a check to
>>> validate that the struct device is correct before invoking any domain op
>>> that accepts a struct device.
>>
>> In fact this even describes exactly that - "Store the iommu_ops pointer
>> in the iommu_domain", vs. the "Store the iommu_ops pointer in the
>> iommu_domain_ops" which the patch is actually doing :/
> 
> Will fix that.

Well, as before I'd prefer to make the code match the commit message - 
if I really need to spell it out, see below - since I can't imagine that 
we should ever have need to identify a set of iommu_domain_ops in 
isolation, therefore I think it's considerably clearer to use the 
iommu_domain itself. However, either way we really don't need this yet, 
so we may as well just go ahead and remove the redundant test from VFIO 
anyway, and I can add some form of this patch to my dev branch for now.

Thanks,
Robin.

----->8-----
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index cde2e1d6ab9b..72990edc9314 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1902,6 +1902,7 @@ static struct iommu_domain 
*__iommu_domain_alloc(struct device *dev,
  	domain->type = type;
  	/* Assume all sizes by default; the driver may override this later */
  	domain->pgsize_bitmap = ops->pgsize_bitmap;
+	domain->owner = ops;
  	if (!domain->ops)
  		domain->ops = ops->default_domain_ops;

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 6f64cbbc6721..79e557207f53 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -89,6 +89,7 @@ struct iommu_domain_geometry {

  struct iommu_domain {
  	unsigned type;
+	const struct iommu_ops *owner; /* Who allocated this domain */
  	const struct iommu_domain_ops *ops;
  	unsigned long pgsize_bitmap;	/* Bitmap of page sizes in use */
  	iommu_fault_handler_t handler;

  reply	other threads:[~2022-06-06 17:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06  6:19 [PATCH 0/5] Simplify vfio_iommu_type1 attach/detach routine Nicolin Chen
2022-06-06  6:19 ` [PATCH 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group Nicolin Chen
2022-06-07  3:23   ` Baolu Lu
2022-06-07  4:03     ` Nicolin Chen
2022-06-08  7:49   ` Tian, Kevin
2022-06-08 17:38     ` Nicolin Chen
2022-06-06  6:19 ` [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain Nicolin Chen
2022-06-06 14:33   ` Robin Murphy
2022-06-06 16:51     ` Nicolin Chen
2022-06-06 17:50       ` Robin Murphy [this message]
2022-06-06 18:28         ` Nicolin Chen
2022-06-06 18:52           ` Jason Gunthorpe
2022-06-06  6:19 ` [PATCH 3/5] vfio/iommu_type1: Prefer to reuse domains vs match enforced cache coherency Nicolin Chen
2022-06-08  8:28   ` Tian, Kevin
2022-06-08 11:17     ` Jason Gunthorpe
2022-06-08 23:48       ` Tian, Kevin
2022-06-14 20:45         ` Nicolin Chen
2022-06-15  7:35           ` Tian, Kevin
2022-06-15 23:12             ` Nicolin Chen
2022-06-06  6:19 ` [PATCH 4/5] vfio/iommu_type1: Clean up update_dirty_scope in detach_group() Nicolin Chen
2022-06-08  8:35   ` Tian, Kevin
2022-06-08 17:46     ` Nicolin Chen
2022-06-06  6:19 ` [PATCH 5/5] vfio/iommu_type1: Simplify group attachment Nicolin Chen
2022-06-07  7:44 ` [PATCH 0/5] Simplify vfio_iommu_type1 attach/detach routine Baolu Lu
2022-06-07 11:58   ` Jason Gunthorpe
2022-06-07 12:42     ` Baolu Lu

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=6575de6d-94ba-c427-5b1e-967750ddff23@arm.com \
    --to=robin.murphy@arm.com \
    --cc=agross@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=alim.akhtar@samsung.com \
    --cc=alyssa@rosenzweig.io \
    --cc=baolin.wang7@gmail.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jgg@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=kvm@vger.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-sunxi@lists.linux.dev \
    --cc=linux-tegra@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=marcan@marcan.st \
    --cc=matthias.bgg@gmail.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=nicolinc@nvidia.com \
    --cc=orsonzhai@gmail.com \
    --cc=robdclark@gmail.com \
    --cc=samuel@sholland.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=sven@svenpeter.dev \
    --cc=thierry.reding@gmail.com \
    --cc=vdumpa@nvidia.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wens@csie.org \
    --cc=will@kernel.org \
    --cc=yong.wu@mediatek.com \
    --cc=zhang.lyra@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).