From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
Christoph Hellwig <hch@lst.de>,
"Derrick, Jonathan" <jonathan.derrick@intel.com>
Subject: Re: [PATCH 4/5] PCI/vmd: Stop overriding dma_map_ops
Date: Thu, 29 Aug 2019 16:14:53 +0200 [thread overview]
Message-ID: <20190829141453.GC18677@lst.de> (raw)
In-Reply-To: <20190828150106.GD23412@localhost.localdomain>
On Wed, Aug 28, 2019 at 09:01:06AM -0600, Keith Busch wrote:
> On Wed, Aug 28, 2019 at 07:14:42AM -0700, Christoph Hellwig wrote:
> > With a little tweak to the intel-iommu code we should be able to work
> > around the VMD mess for the requester IDs without having to create giant
> > amounts of boilerplate DMA ops wrapping code. The other advantage of
> > this scheme is that we can respect the real DMA masks for the actual
> > devices, and I bet it will only be a matter of time until we'll see the
> > first DMA challeneged NVMe devices.
>
> This tests out fine on VMD hardware, but it's quite different than the
> previous patch. In v1, the original dev was used in iommu_need_mapping(),
> but this time it's the vmd device. Is this still using the actual device's
> DMA mask then?
True. But then again I think the old one was broken as well, as it
will pass the wrong dev to identity_mapping() or
iommu_request_dma_domain_for_dev. So I guess I'll need to respin it
a bit to do the work in iommu_need_mapping again, and then factor
that one to make it obvious what device we deal 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@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
"Derrick, Jonathan" <jonathan.derrick@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"joro@8bytes.org" <joro@8bytes.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/5] PCI/vmd: Stop overriding dma_map_ops
Date: Thu, 29 Aug 2019 16:14:53 +0200 [thread overview]
Message-ID: <20190829141453.GC18677@lst.de> (raw)
In-Reply-To: <20190828150106.GD23412@localhost.localdomain>
On Wed, Aug 28, 2019 at 09:01:06AM -0600, Keith Busch wrote:
> On Wed, Aug 28, 2019 at 07:14:42AM -0700, Christoph Hellwig wrote:
> > With a little tweak to the intel-iommu code we should be able to work
> > around the VMD mess for the requester IDs without having to create giant
> > amounts of boilerplate DMA ops wrapping code. The other advantage of
> > this scheme is that we can respect the real DMA masks for the actual
> > devices, and I bet it will only be a matter of time until we'll see the
> > first DMA challeneged NVMe devices.
>
> This tests out fine on VMD hardware, but it's quite different than the
> previous patch. In v1, the original dev was used in iommu_need_mapping(),
> but this time it's the vmd device. Is this still using the actual device's
> DMA mask then?
True. But then again I think the old one was broken as well, as it
will pass the wrong dev to identity_mapping() or
iommu_request_dma_domain_for_dev. So I guess I'll need to respin it
a bit to do the work in iommu_need_mapping again, and then factor
that one to make it obvious what device we deal with.
next prev parent reply other threads:[~2019-08-29 14:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 14:14 stop overriding dma_ops in vmd v2 Christoph Hellwig
2019-08-28 14:14 ` Christoph Hellwig
2019-08-28 14:14 ` [PATCH 1/5] x86/pci: Remove an ifdef __KERNEL__ from pci.h Christoph Hellwig
2019-08-28 14:14 ` Christoph Hellwig
2019-08-28 14:14 ` [PATCH 2/5] x86/pci: Add a to_pci_sysdata helper Christoph Hellwig
2019-08-28 14:14 ` Christoph Hellwig
2019-08-28 16:41 ` Derrick, Jonathan
2019-08-28 16:41 ` Derrick, Jonathan
2019-08-29 14:13 ` hch
2019-08-29 14:13 ` hch
2019-08-28 14:14 ` [PATCH 3/5] x86/pci: Replace the vmd_domain field with a vmd_dev pointer Christoph Hellwig
2019-08-28 14:14 ` Christoph Hellwig
2019-08-28 14:14 ` [PATCH 4/5] PCI/vmd: Stop overriding dma_map_ops Christoph Hellwig
2019-08-28 14:14 ` Christoph Hellwig
2019-08-28 15:01 ` Keith Busch
2019-08-28 15:01 ` Keith Busch
2019-08-29 14:14 ` Christoph Hellwig [this message]
2019-08-29 14:14 ` Christoph Hellwig
2019-08-28 14:14 ` [PATCH 5/5] x86/pci: Remove X86_DEV_DMA_OPS Christoph Hellwig
2019-08-28 14:14 ` 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=20190829141453.GC18677@lst.de \
--to=hch@lst.de \
--cc=bhelgaas@google.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathan.derrick@intel.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=x86@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.