From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: MMIO ioremap() error with PCI passthrough Date: Tue, 01 Jul 2008 11:52:39 -0700 Message-ID: <486A7CF7.6090202@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Andy Burns , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 1/7/08 14:16, "Andy Burns" wrote: > > >>> The functions look like they should map the correct range of pages (in this >>> case only the page covering FEBFF000-FEBFFFFF) >>> >> Built and installed kernel/modules/initrd, rebooted, when it loads the >> saa7134 driver I see this >> >> REMAP: phys=0xfebffc00, len=4096 >> REMAPPFN: addr=0xffffc20000038000, mfn=0xfebff, size=8192 >> >> So the 1K mapping has been rounded up to 4K (x86_64 page size?) before >> passing to __ioremap() and then rounded up again to 8K by the time it >> gets passed to __direct_remap_pfn_range() is that right? >> > > Well, your analysis is correct, and the size argument to __ioremap() is > bogus. It shouldn't have been rounded up to 4096 without also rounding down > the base address. I don't think this would happen with out linux-2.6.18-xen > tree. In there, ioremap() is defined in include/asm-x86_64/mach-xen/io.h as > a thin wrapper around __ioremap() which does not modify the size parameter. > > So, could be a bug specific to the FC8 kernel. I don't have its sources to > hand to pinpoint where the size is getting changed from 0x400 to 0x1000. You > should be able to dig up that detail pretty easily though. There was a kernel bug in which ioremap would add a 1 page redzone to the end of the mapping, and then pass that extra page to iounmap. It has been fixed for a while, but since F8. J