[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Question about i386 ioremap()
Mark, Thank you. It all makes sense now. Aravindh > -----Original Message----- > From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx] > Sent: Thursday, November 03, 2005 10:47 AM > To: Puthiyaparambil, Aravindh > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-devel] Question about i386 ioremap() > > > > Sounds OK to me; what part did you disagree with? > > > > "The returned address is not guaranteed to be usable directly as a > > virtual address." > > > > Why this should hold true for ioremap()? I see that this can be the case > > for ioremap_nocache(). > > It's for compatibility with other architectures. On x86 you *can* access > the > memory directly from a pointer but it's non-portable to do so, which is > why > Linux has the mmio macros. I'm sure you can also access uncached io > memory > through virtual addresses on x86, it would just mark it as uncached in the > page table. Again, other architectures may handle this case > differently... > > > Furthermore if this comment is true, then please look at comments about > > __ioremap() and __ioremap_nocache() in arch/xen/i386 or > > x86_64/mm/ioremap.c. The comment I see for ioremap() is > > > > /* > > * Remap an arbitrary physical address space into the kernel virtual > > * address space. Needed when the kernel wants to access high addresses > > * directly. > > That's referring to the x86 implementation of ioremap - may not apply on > other > architectures. The comment you originally posted more accurately > describes > the general usage of ioremap. On x86 you actually do access IO memory by > normal accesses to virtual addresses. On other platforms this isn't the > case, so ioremap may be returning some kind of "cookie" to allow later > accesses to the IO region. > > Since x86 does let you dereference the "pointer" returned by ioremap(), > people > sometimes write drivers that do just that; this is a bug - the "sparse" > checker is used (amongst other things) to search the source tree for iomem > addresses being deferenced directly and fix them to use the portable > macros. > > I had a poke around the source tree to find an example where things were > different... Took a while to find but Sparc64 seems to do something > interesting: see include/asm-sparc64/io.h. The ioremap implementation > doesn't map the IO memory at all, it just returns the physical address it > was > passed. The readb, writeb, etc macros perform direct physical address > accesses, bypassing virtual-physical translation entirely. > > Does that answer your question? > > Cheers, > Mark > > > I am little confused here :-) > > > > Aravindh > > > > > -----Original Message----- > > > From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx] > > > Sent: Thursday, November 03, 2005 6:59 AM > > > To: xen-devel@xxxxxxxxxxxxxxxxxxx > > > Cc: Puthiyaparambil, Aravindh > > > Subject: Re: [Xen-devel] Question about i386 ioremap() > > > > > > > /** > > > > * ioremap - map bus memory into CPU space > > > > * @offset: bus address of the memory > > > > * @size: size of the resource to map > > > > * > > > > * ioremap performs a platform specific sequence of operations to > > > > * make bus memory CPU accessible via the readb/readw/readl/writeb/ > > > > * writew/writel functions and the other mmio helpers. The returned > > > > * address is not guaranteed to be usable directly as a virtual > > > > * address. > > > > */ > > > > > > > > Is this correct? Isn't this true only in the case of > > > > ioremap_nocache()? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |