ARM page tables

DISCUSSION Mason 2 participants 5 messages Dec 9, 2014 – Dec 10, 2014

lore

Share & tools

lore

Mason

author

2014-12-09 17:21 UTC #0 lore raw

Hello everyone,

On my SoC, we have two MMIO regions mapped at init:

{
.virtual = (0xf0000000 + 0x00800000),
.pfn =((unsigned long)((0x20000000) >> 12)),
.length = 0x00200000,
.type = 0,
},
{
.virtual = (0xf0000000 +(0)),
.pfn =((unsigned long)((0) >> 12)),
.length = 0x00800000,
.type = 0,
},

I dumped the L1 page table descriptors, expecting to find entries for the MMIO regions:
(AFAICT, the page table starts at 0xc0007000)

col_1 = entry number (hex)
col_2 = entry value
col_3 = string for (desc & 3)

300 00011452 SECTION
301 00111452 SECTION
302 00211452 SECTION
303 00311452 SECTION
304 00411452 SECTION
305 00511452 SECTION
306 00611452 SECTION
307 00711452 SECTION
308 20011452 SECTION
309 20111452 SECTION

If I understand correctly, entry 308 means:
VIRTUAL ADDRESS 0x3080_0000 is mapped to PHYSICAL ADDRESS 0x2000_0000 (Is my reading correct?)

But we asked to map PA 0x2000_0000 to VA 0xf080_0000 in iotable_init, so I'm confused...

Also, looking at entry 300:
VA 0x3000_0000 to PA 0
but we asked for VA 0xf000_0000 didn't we?

Can someone clear my confusion?

Regards.

Russell King - ARM Linux

2014-12-09 17:27 UTC #1 lore raw

Quoted 15 lines · Mason

On my SoC, we have two MMIO regions mapped at init:
{
.virtual = (0xf0000000 + 0x00800000),
.pfn =((unsigned long)((0x20000000) >> 12)),
.length = 0x00200000,
.type = 0,
},
{
.virtual = (0xf0000000 +(0)),
.pfn =((unsigned long)((0) >> 12)),
.length = 0x00800000,
.type = 0,
},

Quoted 3 lines

I dumped the L1 page table descriptors, expecting to find entries for the MMIO regions:
(AFAICT, the page table starts at 0xc0007000)

No, it starts at 0xc0004000.

Quoted 15 lines

col_1 = entry number (hex)
col_2 = entry value
col_3 = string for (desc & 3)
300 00011452 SECTION
301 00111452 SECTION
302 00211452 SECTION
303 00311452 SECTION
304 00411452 SECTION
305 00511452 SECTION
306 00611452 SECTION
307 00711452 SECTION
308 20011452 SECTION
309 20111452 SECTION

Quoted 3 lines

If I understand correctly, entry 308 means:
VIRTUAL ADDRESS 0x3080_0000 is mapped to PHYSICAL ADDRESS 0x2000_0000 (Is my reading correct?)

No. If you're talking about 0x308 from an offset of 0x3000 into the page table, that's 0x308 * 1MB + 0xc0000000 = 0xf0800000.

Quoted 2 lines

But we asked to map PA 0x2000_0000 to VA 0xf080_0000 in iotable_init, so I'm confused...

So, with the right starting point, it works out correctly.

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Mason

author

2014-12-09 22:59 UTC #2 lore raw

Hello Russel,

Quoted 16 lines · Russell King - ARM Linux

Quoted 15 lines · Mason
On my SoC, we have two MMIO regions mapped at init:
{
.virtual = (0xf0000000 + 0x00800000),
.pfn =((unsigned long)((0x20000000) >> 12)),
.length = 0x00200000,
.type = 0,
},
{
.virtual = (0xf0000000 +(0)),
.pfn =((unsigned long)((0) >> 12)),
.length = 0x00800000,
.type = 0,
},

Quoted 5 lines

Quoted 3 lines
I dumped the L1 page table descriptors, expecting to find entries for the MMIO regions:
(AFAICT, the page table starts at 0xc0007000)
No, it starts at 0xc0004000.

I should have suspected that I had the wrong start address. Thanks! What's the name of the symbolic constant for that address?

The page table is allocated in pgd_alloc, right?
new_pgd = __pgd_alloc();
#define __pgd_alloc() (pgd_t *)__get_free_pages(GFP_KERNEL | __GFP_REPEAT, 2)

If that's the correct init code, how does it guarantee to always return 0xc0004000?

Quoted 19 lines

Quoted 15 lines
col_1 = entry number (hex)
col_2 = entry value
col_3 = string for (desc & 3)
300 00011452 SECTION
301 00111452 SECTION
302 00211452 SECTION
303 00311452 SECTION
304 00411452 SECTION
305 00511452 SECTION
306 00611452 SECTION
307 00711452 SECTION
308 20011452 SECTION
309 20111452 SECTION
Quoted 3 lines
If I understand correctly, entry 308 means:
VIRTUAL ADDRESS 0x3080_0000 is mapped to PHYSICAL ADDRESS 0x2000_0000 (Is my reading correct?)

Quoted 7 lines

No. If you're talking about 0x308 from an offset of 0x3000 into the page table, that's 0x308 * 1MB + 0xc0000000 = 0xf0800000.
Quoted 2 lines
But we asked to map PA 0x2000_0000 to VA 0xf080_0000 in iotable_init, so I'm confused...
So, with the right starting point, it works out correctly.

Indeed!

I am investigating this issue:

As I described, we map PA 0-8MB. But some code actually accesses address 0xf0920000 (from kernel space) and I was expecting very nasty things, like the equivalent of SIGSEGV in the kernel. But nothing happens, no page fault, no BUG_ON, no panic, no implosion... (Writes seem ignored, and reads always return 0)

I don't understand how it is possible to access unmapped virtual addresses without the MMU throwing a fit... That's why I'm looking at the page table.

Regards.

Russell King - ARM Linux

2014-12-10 00:16 UTC #3 lore raw

Quoted 9 lines · Mason

Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Mason
{
.virtual = (0xf0000000 +(0)),
.pfn =((unsigned long)((0) >> 12)),
.length = 0x00800000,
.type = 0,
},
What's the name of the symbolic constant for that address?

swapper_pg_dir

Quoted 10 lines

Quoted 10 lines
Quoted 10 lines
300 00011452 SECTION
301 00111452 SECTION
302 00211452 SECTION
303 00311452 SECTION
304 00411452 SECTION
305 00511452 SECTION
306 00611452 SECTION
307 00711452 SECTION
308 20011452 SECTION
309 20111452 SECTION

...

Quoted 7 lines

I am investigating this issue:
As I described, we map PA 0-8MB. But some code actually accesses address 0xf0920000 (from kernel space) and I was expecting very nasty things, like the equivalent of SIGSEGV in the kernel. But nothing happens, no page fault, no BUG_ON, no panic, no implosion... (Writes seem ignored, and reads always return 0)

As we can see above, you asked for 0x00200000 bytes to be mapped from 0xf0800000. So, 0xf0800000 to 0xf09fffff will be mapped. The address which you are accessing falls within this range.

So, there's a valid mapping. Assuming nothing on the bus raises an external abort, accesses to this address will succeed.

Quoted 3 lines

I don't understand how it is possible to access unmapped virtual addresses without the MMU throwing a fit... That's why I'm looking at the page table.

You _have_ asked for that address to be mapped.

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Mason

author

2014-12-10 09:41 UTC #4 lore raw

Hello Russel,

Quoted 5 lines · Russell King

Quoted 1 line · Mason
What's the name of the address of the page table?
swapper_pg_dir

Got it.
arch/arm/kernel/head.S

/*
* swapper_pg_dir is the virtual address of the initial page table. */
.equ swapper_pg_dir, KERNEL_RAM_VADDR - PG_DIR_SIZE

#define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET)

PAGE_OFFSET = 0xC0000000
TEXT_OFFSET = $(textofs-y) = 0x00008000
PG_DIR_SIZE = 0x4000

Thus, in my case, swapper_pg_dir = 0xC0004000

Quoted 6 lines

As we can see above, you asked for 0x00200000 bytes to be mapped from 0xf0800000. So, 0xf0800000 to 0xf09fffff will be mapped. The address which you are accessing falls within this range.
So, there's a valid mapping. Assuming nothing on the bus raises an external abort, accesses to this address will succeed.

I was looking so hard for the tree, that I completely missed the forest. Thanks for clearing my confusion.

By the way, wrt to the thread "Creating 16 MB super-sections for MMIO". I'm thinking of writing a quick-and-dirty patch to test the impact on our SoC of using a super-section for the 0-16MB region. Would there be any interest in mainlining that?

Regards.