question on remap_page_range()

question on remap_page_range()

[Gilles Pokam]

Hi everyone,

I have some questions about the behavior of the remap_page_range function as 
well as the ioremap. 

1. remap_page_range (as well as ioremap or vremap) takes a "physical address"
   as argument. In Rubini's book it is said that the so-called "physical
   address" is in reality a virtual address offset by PAGE_OFFSET from the 
   real physical address:
	phys = real_phys + PAGE_OFFSET 
   In x86 2.0.x kernel i had no problems with this convertion because the
   PAGE_OFFSET is almost defined to be 0, so that phys = virt address.

2. But now i have tried to run my code on a x86 2.2.x kernel and the 
   remap_page_range function fails! When i ignore the PAGE_OFFSET macro
   it works strangely ...! 

  My question is, what is the definition of the physical address in the
  remap_page_range and vremap functions ?

  Regards 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: question on remap_page_range()

[Stephen C. Tweedie]

Hi,

On Sat, 28 Aug 1999 12:03:41 +0200 (MET DST), Gilles Pokam
<pokam@cs.tu-berlin.de> said:

> I have some questions about the behavior of the remap_page_range function as 
> well as the ioremap. 

> 1. remap_page_range (as well as ioremap or vremap) takes a "physical address"
>    as argument. 

Yes.

>    In Rubini's book it is said that the so-called "physical
>    address" is in reality a virtual address offset by PAGE_OFFSET from the 
>    real physical address:

No.  Either Rubini is wrong or you have misinterpreted.  A physical
address is just that --- the physical address of the memory as it
appears on the cpu bus when the cpu goes to read from ram.  It is
completely untranslated.  The first physical address in the system is
usually zero, not PAGE_OFFSET.  

> 	phys = real_phys + PAGE_OFFSET 

No, phys == real_phys.  The *virtual* address is real_phys +
PAGE_OFFSET.  You can convert between the two using phys_to_virt() and
virt_to_phys().

>    In x86 2.0.x kernel i had no problems with this convertion because the
>    PAGE_OFFSET is almost defined to be 0, so that phys = virt address.

That is because 2.0 hid the physical/virtual translation behind a layer
of i386 segmentation tricks.

> 2. But now i have tried to run my code on a x86 2.2.x kernel and the 
>    remap_page_range function fails! When i ignore the PAGE_OFFSET macro
>    it works strangely ...! 

Yes.  remap_page_range is designed to remap real, honest physical
addresses.  These addresses have no translation applied:
remap_page_range is supposed to be able to work even if applied to some
physical address that is outside the normal kernel virtual address
translation pages (eg. video framebuffers).

>   My question is, what is the definition of the physical address in the
>   remap_page_range and vremap functions ?

Physical == physical.  There's nothing fancy going on.  Only when you
start using virtual addresses do the numbers change.

Read linux/Documentation/IO-mapping.txt for all the gory details.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: question on remap_page_range()

[Gilles Pokam]

On Sun, 29 Aug 1999, Stephen C. Tweedie wrote:
> 
> On Sat, 28 Aug 1999 12:03:41 +0200 (MET DST), Gilles Pokam
> <pokam@cs.tu-berlin.de> said:
> 
> >    In Rubini's book it is said that the so-called "physical
> >    address" is in reality a virtual address offset by PAGE_OFFSET from the 
> >    real physical address:
> 
> No.  Either Rubini is wrong or you have misinterpreted.  A physical
> address is just that --- the physical address of the memory as it
> appears on the cpu bus when the cpu goes to read from ram.  It is
> completely untranslated.  The first physical address in the system is
> usually zero, not PAGE_OFFSET.  

Sorry, i forget to said "from the kernel point of vue" :

Rubini's book, page 274 about PAGE_OFFSET:

" (...) PAGE_OFFSET must be considered whenever "physical" addresses are
used. What the kernel considers to be a physical address is actually a
virtual address, offset by PAGE_OFFSET from the real physical
address.(..)"

> > 	phys = real_phys + PAGE_OFFSET 
> 
> No, phys == real_phys.  The *virtual* address is real_phys +
> PAGE_OFFSET.  You can convert between the two using phys_to_virt() and
> virt_to_phys().

In this sense Rubini means that : kernel physical address = virtual
address ??

> > 2. But now i have tried to run my code on a x86 2.2.x kernel and the 
> >    remap_page_range function fails! When i ignore the PAGE_OFFSET macro
> >    it works strangely ...! 
> 
> Yes.  remap_page_range is designed to remap real, honest physical
> addresses.  These addresses have no translation applied:
> remap_page_range is supposed to be able to work even if applied to some
> physical address that is outside the normal kernel virtual address
> translation pages (eg. video framebuffers).

About remap_page_range Rubini said: (page 280-281)
" remap_page_range(unsigned long virt_addr,unsigned long phys_add,
	          unsigned log size,pgprot_t prot);
 unsigned long phys_add:
    The phyical address to which the virtual address should be mapped. The
    address is physical in the sense outline above" (in PAGE_OFFSET)
 
To map to user space a region of memory beginning at physical address
simple_region_start with size = simple_region_size he used the following
example:
unsigned long physical = simple_region_start + off + PAGE_OFFSET

physical was the argument passed to the remap_page_range function. I was
confusing here because the remap_page_range function in this example  
seems to take a virtual address instead of the real physical address.

Thanks
--

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: question on remap_page_range()

[Stephen C. Tweedie]

Hi,

On Tue, 31 Aug 1999 10:23:37 +0200 (MET DST), Gilles Pokam
<pokam@cs.tu-berlin.de> said:

>> No.  Either Rubini is wrong or you have misinterpreted.  A physical
>> address is just that --- the physical address of the memory as it
>> appears on the cpu bus when the cpu goes to read from ram.  It is
>> completely untranslated.  The first physical address in the system is
>> usually zero, not PAGE_OFFSET.  

> Sorry, i forget to said "from the kernel point of vue" :

> Rubini's book, page 274 about PAGE_OFFSET:

> " (...) PAGE_OFFSET must be considered whenever "physical" addresses are
> used. What the kernel considers to be a physical address is actually a
> virtual address, offset by PAGE_OFFSET from the real physical
> address.(..)"

That is wrong.  A physical address is a physical address is a physical
address.  Even from the kernel's point of view.  We need to know
physical addresses when we are setting up page tables, for example, and
these do NOT have a PAGE_OFFSET applied.  Ever.

However, the kernel cannot directly access the contents of a physical
address in memory: all memory accesses, without exception, go through
virtual address translation, and _that_ is where PAGE_OFFSET comes in.

Physical addresses do not, ever, include the PAGE_OFFSET bias.

It would be true to say that "What the kernel uses to *access* a
physicall address is actually a virtual address, offset by PAGE_OFFSET
from the real physical addres."  However, the kernel still calls that
latter, offset address a virtual address, not a physical address.  It's
a kernel virtual address as opposed to a user virtual address, but it is
still virtual, not physical.

> About remap_page_range Rubini said: (page 280-281)
> " remap_page_range(unsigned long virt_addr,unsigned long phys_add,
> 	          unsigned log size,pgprot_t prot);
>  unsigned long phys_add:
>     The phyical address to which the virtual address should be mapped. The
>     address is physical in the sense outline above" (in PAGE_OFFSET)

That is nonsense, the physaddr in remap_page_range does not include
PAGE_OFFSET bias.  It makes no sense at all for it to do so.

> To map to user space a region of memory beginning at physical address
> simple_region_start with size = simple_region_size he used the following
> example:
> unsigned long physical = simple_region_start + off + PAGE_OFFSET

That will work on 2.0, but only because PAGE_OFFSET is zero.  It won't
work on 2.2.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/