[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8cad7eb5b5b37aeb041fd0c464383bb5223e4a64.camel@intel.com>
Date: Tue, 27 Aug 2019 18:24:05 +0000
From: "Derrick, Jonathan" <jonathan.derrick@...el.com>
To: "hch@....de" <hch@....de>, "x86@...nel.org" <x86@...nel.org>
CC: "joro@...tes.org" <joro@...tes.org>,
"Busch, Keith" <keith.busch@...el.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] vmd: Stop overriding dma_map_ops
On Mon, 2019-08-26 at 17:06 +0200, 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.
>
> The only downside is that we can't offer vmd as a module given that
> intel-iommu calls into it. But the driver only has about 700 lines
> of code, so this should not be a major issue.
If we're going to remove its ability to be a module, and given its
small size, could we make this default =y?
Otherwise we risk breaking platforms which have it enabled with OSVs
who miss enabling it
>
> This also removes the leftover bits of the X86_DEV_DMA_OPS dma_map_ops
> registry.
>
> Signed-off-by: Christoph Hellwig <hch@....de>
>
lgtm otherwise
Reviewed-by: Jon Derrick <jonathan.derrick@...el.com>
Powered by blists - more mailing lists