RE: [Xen-devel] Question about i386 ioremap()

["Puthiyaparambil, Aravindh" <aravindh.puthiyaparambil@xxxxxxxxxx>]

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