public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Christoph Hellwig <hch@infradead.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.com>,
	Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] iommu: Replace detach_dev with real blocking domains
Date: Fri, 26 Aug 2022 12:34:45 -0300	[thread overview]
Message-ID: <YwjoFXLFIGo8s2YH@nvidia.com> (raw)
In-Reply-To: <20220826123014.52709-2-baolu.lu@linux.intel.com>

On Fri, Aug 26, 2022 at 08:30:12PM +0800, Lu Baolu wrote:
> From iommu core's point of view, detaching a domain from a device is
> equal to attaching the group's blocking domain to the device. This
> repalces all detach_dev callbacks in the IOMMU drivers with a real
> blocking domain and handles detaching domain through it.

There is a subtly here, where detach_dev() is not *always* going to a
blocking domain. Recall we made this mistaken when building the owner
series and it is why the blocking domain was introduced.

The challenge with this work is to be sure that the code you assigned
to the blocking domain doesn't actually set an identity domain or
set things to use the platform DMA ops.

> +static int blocking_domain_attach_dev(struct iommu_domain *_domain,
> +				      struct device *dev)
> +{
> +	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> +
> +	s390_iommu_detach_device(domain, dev);
> +
> +	return 0;
> +}

For instance, I know that this is returning the group back to the
platform DMA ops.

To really make progress on this I would suggest

1) Remove detach_dev from drivers that don't use it. This is any
   driver that provides a default domain, if a default domain is set
   then we always use attach_dev(default_domain) and never detach_dev

2) Of those drivers in #1 audit and try to determine if their
   detach_dev is doing blocking domain behavior and if yes give them a
   real blocking domain. Otherwise just delete the code.

3) The remaining drivers are not using default_domain. Rename
   'detach_dev' to iommu_ops->set_platform_dma(dev) to make it clear
   that what it is doing is returning control back to the platform DMA
   ops.

I would do one patch per driver on the blocking domain conversions and
get acks from the driver owners. Do as many as can be acked, delete
the rest.

Make it clear to driver owners checking that blocking domain must halt
all DMA, and it must not be a passthrough or identity behavior.

When last I looked several of the drivers looked like they were
setting an identity domain on the detach_dev - eg back to a boot time
behavior where the iommu is bypassed. It is really important these not
be converted to blocking :) Arguably if they can be found they should
be converted to identity domains instead.

Jason

  reply	other threads:[~2022-08-26 15:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 12:30 [PATCH v2 0/3] iommu: Retire detach_dev callback Lu Baolu
2022-08-26 12:30 ` [PATCH v2 1/3] iommu: Replace detach_dev with real blocking domains Lu Baolu
2022-08-26 15:34   ` Jason Gunthorpe [this message]
2022-08-29  3:49     ` Baolu Lu
2022-08-26 12:30 ` [PATCH v2 2/3] iommu: Retire detach_dev domain ops Lu Baolu
2022-08-26 12:30 ` [PATCH v2 3/3] iommu: Rename attach_dev to set_dev Lu Baolu

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=YwjoFXLFIGo8s2YH@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=eric.auger@redhat.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@intel.com \
    --cc=jean-philippe@linaro.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.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