WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Puthiyaparambil, Aravindh" <aravindh.puthiyaparambil@xxxxxxxxxx>
Subject: Re: [Xen-devel] Question about i386 ioremap()
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 3 Nov 2005 15:46:49 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 03 Nov 2005 15:44:54 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <EF8D308BE33AF54D8934DF26520252D30305E214@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <EF8D308BE33AF54D8934DF26520252D30305E214@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.3
> > 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

<Prev in Thread] Current Thread [Next in Thread>