All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Stuart Yoder <stuyoder@gmail.com>,
	rafael@kernel.org, David Airlie <airlied@linux.ie>,
	linux-pci@vger.kernel.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Diana Craciun <diana.craciun@oss.nxp.com>,
	Dmitry Osipenko <digetx@gmail.com>, Will Deacon <will@kernel.org>,
	Ashok Raj <ashok.raj@intel.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Christoph Hellwig <hch@infradead.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cornelia Huck <cohuck@redhat.com>,
	linux-kernel@vger.kernel.org, Li Yang <leoyang.li@nxp.com>,
	iommu@lists.linux-foundation.org,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v1 5/8] iommu/amd: Use iommu_attach/detach_device()
Date: Tue, 15 Feb 2022 10:11:01 +0100	[thread overview]
Message-ID: <YgtuJQhY8SNlv9/6@8bytes.org> (raw)
In-Reply-To: <20220214150059.GE4160@nvidia.com>

On Mon, Feb 14, 2022 at 11:00:59AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
> 
> > Device drivers calling into iommu_attach_device() is seldom a good
> > idea.  In this case the sound device has some generic hardware
> > interface so that an existing sound driver can be re-used. Making this
> > driver call iommu-specific functions for some devices is something hard
> > to justify.
> 
> Er, so this is transparent to the generic sound device? I guess
> something fixed up the dma_api on that device to keep working?

Right, this is completly transparent to the sound device. The IOMMU code
will not set dma_ops on the device because it uses a direct mapping and
so the standard implementation will be used.

> But, then, the requirement is that nobody is using the dma API when we
> make this change?

That is the tricky part. DMA-API keeps working after the change is made,
because the new domain is also direct mapped. The new domain just has
the ability to assign host page-tables to device PASIDs, so that DMA
requests with a PASID TLP will be remapped.

It was actually a requirement for this code that when it jumps in, the
DMA-API mappings stay live. And the reason a direct mapping is used at
all is that the page-table walker of the IOMMU is a two-dimensional
walker, which will treat the addresses found in the host page-tables as
IO-virtual an translates them through the underlying page-table. So to
use host-pagetables the underlying mapping must be direct mapped.


> I don't think it matters how big/small the group is, only that when we
> change the domain we know everything flowing through the domain is
> still happy.

Yes, that matters. The group size matters too for DMA-API performance.
If two devices compete for the same lock in the allocator and/or the
same cached magazines, things will slow down. That only matters for
high-throughput devices, but still...

Regards,

	Joerg

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@infradead.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Will Deacon <will@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	rafael@kernel.org, Diana Craciun <diana.craciun@oss.nxp.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Stuart Yoder <stuyoder@gmail.com>,
	Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Li Yang <leoyang.li@nxp.com>, Dmitry Osipenko <digetx@gmail.com>,
	iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 5/8] iommu/amd: Use iommu_attach/detach_device()
Date: Tue, 15 Feb 2022 10:11:01 +0100	[thread overview]
Message-ID: <YgtuJQhY8SNlv9/6@8bytes.org> (raw)
In-Reply-To: <20220214150059.GE4160@nvidia.com>

On Mon, Feb 14, 2022 at 11:00:59AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
> 
> > Device drivers calling into iommu_attach_device() is seldom a good
> > idea.  In this case the sound device has some generic hardware
> > interface so that an existing sound driver can be re-used. Making this
> > driver call iommu-specific functions for some devices is something hard
> > to justify.
> 
> Er, so this is transparent to the generic sound device? I guess
> something fixed up the dma_api on that device to keep working?

Right, this is completly transparent to the sound device. The IOMMU code
will not set dma_ops on the device because it uses a direct mapping and
so the standard implementation will be used.

> But, then, the requirement is that nobody is using the dma API when we
> make this change?

That is the tricky part. DMA-API keeps working after the change is made,
because the new domain is also direct mapped. The new domain just has
the ability to assign host page-tables to device PASIDs, so that DMA
requests with a PASID TLP will be remapped.

It was actually a requirement for this code that when it jumps in, the
DMA-API mappings stay live. And the reason a direct mapping is used at
all is that the page-table walker of the IOMMU is a two-dimensional
walker, which will treat the addresses found in the host page-tables as
IO-virtual an translates them through the underlying page-table. So to
use host-pagetables the underlying mapping must be direct mapped.


> I don't think it matters how big/small the group is, only that when we
> change the domain we know everything flowing through the domain is
> still happy.

Yes, that matters. The group size matters too for DMA-API performance.
If two devices compete for the same lock in the allocator and/or the
same cached magazines, things will slow down. That only matters for
high-throughput devices, but still...

Regards,

	Joerg


  reply	other threads:[~2022-02-15  9:11 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06  2:20 [PATCH v1 0/8] Scrap iommu_attach/detach_group() interfaces Lu Baolu
2022-01-06  2:20 ` Lu Baolu
2022-01-06  2:20 ` [PATCH v1 1/8] iommu: Add iommu_group_replace_domain() Lu Baolu
2022-01-06  2:20   ` Lu Baolu
2022-01-06 17:06   ` Jason Gunthorpe via iommu
2022-01-06 17:06     ` Jason Gunthorpe
2022-01-07  0:26     ` Lu Baolu
2022-01-07  0:26       ` Lu Baolu
2022-02-14 12:09   ` Robin Murphy
2022-02-14 12:09     ` Robin Murphy
2022-02-14 12:45     ` Jason Gunthorpe via iommu
2022-02-14 12:45       ` Jason Gunthorpe
2022-02-14 14:10       ` Robin Murphy
2022-02-14 14:10         ` Robin Murphy
2022-02-14 14:56         ` Jason Gunthorpe via iommu
2022-02-14 14:56           ` Jason Gunthorpe
2022-02-14 16:38           ` Robin Murphy
2022-02-14 16:38             ` Robin Murphy
2022-02-14 17:25             ` Jason Gunthorpe via iommu
2022-02-14 17:25               ` Jason Gunthorpe
2022-01-06  2:20 ` [PATCH v1 2/8] vfio/type1: Use iommu_group_replace_domain() Lu Baolu
2022-01-06  2:20   ` Lu Baolu
2022-01-06  2:20 ` [PATCH v1 3/8] iommu: Extend iommu_at[de]tach_device() for multi-device groups Lu Baolu
2022-01-06  2:20   ` Lu Baolu
2022-01-06 17:22   ` Jason Gunthorpe via iommu
2022-01-06 17:22     ` Jason Gunthorpe
2022-01-07  1:14     ` Lu Baolu
2022-01-07  1:14       ` Lu Baolu
2022-01-07  1:19       ` Jason Gunthorpe via iommu
2022-01-07  1:19         ` Jason Gunthorpe
2022-02-14 11:39   ` Joerg Roedel
2022-02-14 11:39     ` Joerg Roedel
2022-02-14 13:03     ` Jason Gunthorpe via iommu
2022-02-14 13:03       ` Jason Gunthorpe
2022-02-14 14:39       ` Joerg Roedel
2022-02-14 14:39         ` Joerg Roedel
2022-02-14 15:18         ` Robin Murphy
2022-02-14 15:18           ` Robin Murphy
2022-02-14 15:46           ` Jason Gunthorpe via iommu
2022-02-14 15:46             ` Jason Gunthorpe
2022-02-15  8:58             ` Joerg Roedel
2022-02-15  8:58               ` Joerg Roedel
2022-02-15 13:47               ` Jason Gunthorpe via iommu
2022-02-15 13:47                 ` Jason Gunthorpe
2022-02-16  6:28                 ` Lu Baolu
2022-02-16  6:28                   ` Lu Baolu
2022-02-16 13:54                   ` Jason Gunthorpe via iommu
2022-02-16 13:54                     ` Jason Gunthorpe
2022-01-06  2:20 ` [PATCH v1 4/8] drm/tegra: Use iommu_attach/detatch_device() Lu Baolu
2022-01-06  2:20   ` Lu Baolu
2022-01-06  2:20 ` [PATCH v1 5/8] iommu/amd: Use iommu_attach/detach_device() Lu Baolu
2022-01-06  2:20   ` Lu Baolu
2022-01-06 14:33   ` Jason Gunthorpe via iommu
2022-01-06 14:33     ` Jason Gunthorpe
2022-01-07  0:23     ` Lu Baolu
2022-01-07  0:23       ` Lu Baolu
2022-02-14 11:27     ` Joerg Roedel
2022-02-14 11:27       ` Joerg Roedel
2022-02-14 13:15       ` Jason Gunthorpe via iommu
2022-02-14 13:15         ` Jason Gunthorpe
2022-02-14 13:40         ` Joerg Roedel
2022-02-14 13:40           ` Joerg Roedel
2022-02-14 14:02           ` Jason Gunthorpe via iommu
2022-02-14 14:02             ` Jason Gunthorpe
2022-02-14 14:23             ` Joerg Roedel
2022-02-14 14:23               ` Joerg Roedel
2022-02-14 15:00               ` Jason Gunthorpe via iommu
2022-02-14 15:00                 ` Jason Gunthorpe
2022-02-15  9:11                 ` Joerg Roedel [this message]
2022-02-15  9:11                   ` Joerg Roedel
2022-02-15 13:02                   ` Robin Murphy
2022-02-15 13:02                     ` Robin Murphy
2022-02-15 14:37                   ` Jason Gunthorpe via iommu
2022-02-15 14:37                     ` Jason Gunthorpe
2022-01-06  2:20 ` [PATCH v1 6/8] gpu/host1x: " Lu Baolu
2022-01-06  2:20   ` Lu Baolu
2022-01-06 15:35   ` Jason Gunthorpe via iommu
2022-01-06 15:35     ` Jason Gunthorpe
2022-01-07  0:35     ` Lu Baolu
2022-01-07  0:35       ` Lu Baolu
2022-01-07  0:48       ` Jason Gunthorpe via iommu
2022-01-07  0:48         ` Jason Gunthorpe
2022-01-07  1:19         ` Lu Baolu
2022-01-07  1:19           ` Lu Baolu
2022-01-06  2:20 ` [PATCH v1 7/8] media: staging: media: tegra-vde: " Lu Baolu
2022-01-06  2:20   ` Lu Baolu
2022-01-06  2:20 ` [PATCH v1 8/8] iommu: Remove iommu_attach/detach_group() Lu Baolu
2022-01-06  2:20   ` 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=YgtuJQhY8SNlv9/6@8bytes.org \
    --to=joro@8bytes.org \
    --cc=airlied@linux.ie \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=cohuck@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=diana.craciun@oss.nxp.com \
    --cc=digetx@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jgg@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=kch@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=stuyoder@gmail.com \
    --cc=thierry.reding@gmail.com \
    --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.