Re: [PATCH RFC] swiotlb: Remove SWIOTLB overflow buffer support

[Konrad Rzeszutek Wilk]

On Tue, Jul 10, 2012 at 10:55:07AM -0600, Shuah Khan wrote:
> On Mon, 2012-07-09 at 16:25 -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jul 06, 2012 at 05:06:12PM -0600, Shuah Khan wrote:
> > > Remove SWIOTLB overflow buffer support and return DMA_ERROR_CODE
> > > (a value of zero) to make it consistent with iommu implementation
> > > on Intel, AMD, and swiotlb-xen.
> > 
> > While this is a good forward step and this needs to be done eventually,
> > you should first send out patches for the drivers that don't check
> > for the DMA_ERROR_CODE when doing mapping. In other words for the
> > drivers that map but don't call dma_mapping_error to check.
> > 
> > When that is fixed and *all the drivers that don't call dma_mapping_error
> > are fixed, then this patch makes sense.
> 
> The challenge will be catching all the drivers and have confidence that
> all of them are covered. I will start looking into this to get a feel
> for how many drivers needs fixing.

I don't know if all is needed. Some of them might be dead or not used
at all anymore - who knows? This treasure hunt would give a good idea
of which ones are not using the PCI/DMA API right at least.

If it is say, CONFIG_ISA enabled, well, we could #ifdef the overflow
buffer in the swiotlb with that option. And then work through fixing
up those drivers - except that finding folks with that driver to
see if it works .. yuck.. I do have some few ISA cards and some boxes
with ISA slots :-)

> 
> Also, isn't this problem today with other iommu implementations? All of
> the other iommu implementation don't have support for overflow buffers?

Right, but you are in high likehood not going to run the drivers that
don't check this with an IOMMU. Because the drivers are mostly the PCI
variants .. or PCMCIA. And the hardware that would use this did not have
IOMMU.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/