From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: [PATCH] Use lib/swiotlb code for x86_64 SWIOTLB Date: Thu, 22 Feb 2007 10:24:34 +0000 Message-ID: <45DD7D72.76E4.0078.0@novell.com> References: <1449F58C868D8D4E9C72945771150BDFD9660C@SAUSEXMB1.amd.com> <45D57BD5.76E4.0078.0@novell.com> <1449F58C868D8D4E9C72945771150BDFD9664B@SAUSEXMB1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1449F58C868D8D4E9C72945771150BDFD9664B@SAUSEXMB1.amd.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Langsdorf Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> "Langsdorf, Mark" 22.02.07 01:09 >>> >> I can't see how this can work: First, the way the change is >> done i386 will also use that file (and then >> arch/i386/kernel/swiotlb.c should also be deleted by >> the patch). > >That wasn't intentional. i386 can still use the >arch/i386 code. I still don't understand this - both x86 architectures should be able to use the same file. >> Second, there's nothing Xen specific anymore in that file, not >> even the contiguous region creation (the sole difference to >> plain 2.6.20 is the use of virt_to_bus/bus_to_virt). I think >> the first patch should be really just a move of >> arch/i386/kernel/swiotlb.c to lib/swiotlb-xen.c, nothing else. > >This should be an improved version of lib/swiotlb.c as >lib/swiotlb-xen.c, with correct code to make the mappings >contiguous. I still don't understand why this differs more than necessary from arch/i386/swiotlb.c, and I continue to find it more desirable to move arch/i386/swiotlb.c to lib/swiotlb-xen.c first (without any changes) and then have a patch that changes what you really think needs to be changed for your purpose. I'm specifically asking this because I posted changes to lib/swiotlb.c to lkml so that (if all of them get pushed into the kernel.org tree) Xen wouldn't even need its own version anymore, but would just need a header providing certain hooks. Jan Jan