Re: [RFC patch] init default dma_ops to prepare intel_iommu_init failure

[FUJITA Tomonori]

On Thu, 13 Aug 2009 13:48:45 +0800
Luming Yu <luming.yu@xxxxxxxxx> wrote:

> >>
> >> This check can not be removed. Otherwise, swiotlb_dma_ops will always override
> >> previous dma_ops value.
> >
> > Yeah.
> 
> I think pci_swiotlb_init needs to be cleaned up for both x86_{32,64} and ia64.

Yeah, it has been on my todo list. But we can't clean up only
pci_swiotlb_init. We need to take care of the whole dma setup code.


> it should be used to init default dma_ops, and the call site of it should be
> as early as platform_dma_init in mem_init. SInce swiotlb_dma_ops is pitched as
> default dma_ops for x86, ia64,

It's more complicated. x86_32 should use nommu_dma_ops. x86_64 should
use nommu_dma_ops if swiotlb is not necessary.

About IA64, swiotlb is not always available (IA64_HP_ZX1 and
IA64_SIG_SN2).


> we really don't need to let pci_swiotlb_init
> know iommu_deteced, dmar_disabled or iommu_passthrough...and anything
> like that..

Yeah. That's one of reasons why I want to rewrite the IA64 and X86 dma
setup code again.


> Please note the major wrong assumption of the current implementation is
> "iommu_deteced == iommu working" that I was trying to fix.

Yeah, I see that. But it had been correct for long time; we had been
happy about the logic that if we detect iommu but it doesn't work then
we are dead.

The x86 dma setup code can enable both hardware IOMMU and
swiotlb. It's a bit similar to what you need for IA64.


Anyway, my patch should fix this problem. Have you tried it?

http://marc.info/?l=linux-kernel&m=125013354518721&w=2


It's fine for now, I think.
--
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/