| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home