Re: [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu initfailures

[Chris Wright]

* FUJITA Tomonori (fujita.tomonori@xxxxxxxxxxxxx) wrote:
> On Thu, 22 Oct 2009 18:21:58 -0700
> Chris Wright <chrisw@xxxxxxxxxxxx> wrote:
> 
> > This short series gives us the ability to allocate the swiotlb and then
> > conditionally free it if we discover it isn't needed.  This allows us to
> > put swiotlb to use when the hw iommu fails to initialize properly.
> > 
> > This needs some changes to the bootmem allocator to give the ability to
> > free reserved bootmem directly to the page allocator after bootmem is
> > torn down.
> 
> The concept sounds fine but the third patch doesn't look correct.
> 
> Seems that the third patch doesn't take into account enabling both hw
> iommu and swiotlb (Calgary does and I guess VT-d and AMD need that
> too).

VT-d isn't using swiotlb.  Nor is AMD, although I think it will pick up
no_iommu on passthrough (seems like it would benefit from swiotlb in
that case).

>  Also (iommu_detected && !dma_ops) trick doesn't work for
> Calgary, IIRC.

Yes, I think you are right.  I had stared at the calgary code and thought
it would DTRT due to calgary's use of no_iommu as fallback, but instead
it will never pick up swiotlb_dma_ops.  The calgary shouldn't even need
to be manually setting up nommu_dma_ops.

>  The third patch also makes the dma startup code more
> complicated.

I completely agree.  The whole dma/iommu startup is already complex
and fragile.  Issues like above made getting the right combination
like whack-a-mole.

> I have half-baked patches to clean up the dma startup code supporting
> the concept. I can work on the top of the first and second
> patches. They need to be CC'ed to the memory people and ACKs, don't
> they?

Great.
--
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/