Re: [PATCH 0/3] fix GART to respect device's dma_mask aboutvirtual mappings

[FUJITA Tomonori]

On Thu, 18 Sep 2008 20:20:29 +0200
Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

> > The falling back mechanism was moved to pci-nommu from the common code
> > since it doesn't work for other IOMMUs that always need virtual
> 
> There's no fallback for _map_sg/_map_single. All the fallback to GFP
> only works for coherent allocations, but not for streaming mappings.

Yeah, so the falling back mechanism was moved to pci-nommu's
alloc_coherent.


> To make this "fully robust" for masks < 32bit you would need to implement 
> a new swiotlb that uses GFP_DMA allocations as fallback (or use the DMA 
> allocator's swiotlb which can actually handle this)

Do you mean if GART's alloc_coherent can't find a virtual address that
a device can access to, it should try GFP_DMA allocations as fallback?

GART could but why GART should do? If full IOMMUs' alloc_coherent
can't find a virtual address that a device can access to, it's
failure. No fallback is for them. Why can't GART use the same logic?
Yeah, GART is not a full IOMMU, so it can have a fallback for this
case. But why can't GART work in the same way other IOMMUs?


> So you're right now basically checking for something that you cannot
> fix. And also you try to check for (but not handle) something that even 
> 32bit x86 doesn't handle. So if some driver relied on you checking
> for it on 64bit it wouldn't work on 32bit x86 which would be a bad 
> thing.

What does '32bit x86 doesn't handle' mean? pci-nommu's alloc_coherent
can handle < 32bit bit mask in the fallback path.

Or you are talking about '_map_sg/_map_single'? If so, as we
discussed, < 32bit bit mask can be handled in else where. The patch
just tries to return an address that such tricks are not necessary
with.
--
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/