Date: Fri, 23 Oct 2009 14:51:12 +0900
To: chrisw@sous-sol.org
Cc: dwmw2@infradead.org, iommu@lists.linux-foundation.org,
       linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu init
 failures
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
In-Reply-To: <20091023012158.177308035@sequoia.sous-sol.org>
References: <20091023012158.177308035@sequoia.sous-sol.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20091023145054P.fujita.tomonori@lab.ntt.co.jp>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1266
Lines: 26

On Thu, 22 Oct 2009 18:21:58 -0700
Chris Wright <chrisw@sous-sol.org> 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). Also (iommu_detected && !dma_ops) trick doesn't work for
Calgary, IIRC. The third patch also makes the dma startup code more
complicated.

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?


Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/