[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100803143407J.fujita.tomonori@lab.ntt.co.jp>
Date: Tue, 3 Aug 2010 14:35:09 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: konrad.wilk@...cle.com
Cc: fujita.tomonori@....ntt.co.jp, hpa@...or.com, jeremy@...p.org,
Ian.Campbell@...rix.com, albert_herranz@...oo.es, x86@...nel.org,
linux-kernel@...r.kernel.org, jbarnes@...tuousgeek.org,
iommu@...ts.linux-foundation.org, tglx@...utronix.de
Subject: Re: [PATCH 9/9] x86: Detect whether we should use Xen SWIOTLB.
On Mon, 2 Aug 2010 12:42:34 -0400
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> > But his attempt to create "swiotlb iommu function array" and "hardware
> > iommu function array" looks like to makes the code more unreadable.
>
> Let me go to my favorite coffee shop and think this one through.
> Can I get concession for putting the original patch in (the simple, dumb one),
> and then:
> - start working on the IOMMU register interface without having to try
> to get it done for 2.6.36, and
> - do the driverization as a seperate cleanup.
We could simplify swiotlb initialization after 2.6.36. If we merge my
patches to expand swiotlb memory dynamically, we could initialize
swiotlb before any hw IOMMUs (see the commit
186a25026c44d1bfa97671110ff14dcd0c99678e).
If you can make Xen swiotlb initialized like HW iommu, the IOMMU
initialization could be cleaner.
As I wrote, I also want to simplify swiotlb's init memory
allocation. I'll see what I can do on the whole issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists