[lkml]   [2009]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu init failures
* FUJITA Tomonori ( wrote:
> On Thu, 22 Oct 2009 18:21:58 -0700
> Chris Wright <> 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?


 \ /
  Last update: 2009-10-23 18:43    [W:0.082 / U:8.620 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site