Xen devel - Nov 2005 - Question about i386 ioremap()

There is a comment in include/asm-xen/asm-i386/io.h which states:

/**
 * 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()?

Thanks
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> /**
>  * 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()?
Sounds OK to me; what part did you disagree with?

Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 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(). 

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.

I am little confused here :-)

Aravindh
> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@cl.cam.ac.uk]
> Sent: Thursday, November 03, 2005 6:59 AM
> To: xen-devel@lists.xensource.com
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

> > 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@cl.cam.ac.uk]
> > Sent: Thursday, November 03, 2005 6:59 AM
> > To: xen-devel@lists.xensource.com
> > 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Mark,

Thank you. It all makes sense now.

Aravindh
> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@cl.cam.ac.uk]
> Sent: Thursday, November 03, 2005 10:47 AM
> To: Puthiyaparambil, Aravindh
> Cc: xen-devel@lists.xensource.com
> 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@cl.cam.ac.uk]
> > > Sent: Thursday, November 03, 2005 6:59 AM
> > > To: xen-devel@lists.xensource.com
> > > 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@lists.xensource.com
http://lists.xensource.com/xen-devel