How to get section info/offset permissions from windbg/dbgeng api? - visual-studio

I am writing an extension for Windbg, and at a particular point I need to get the permissions for a memory offset, much like how !address addr would provide in Windbg. I have had a look at the available functions of the Debugger Engine API here at:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff551059%28v=vs.85%29.aspx
However I have failed to find such a function that would return the section/permissions information against a memory offset. Basically I would like to get what section the address lies in, data section, text section etc, what permissions it has and so on.
The closest sounding function I have found is GetOffsetInformation in the IDebugDataSpaces4 interface. However as per the documentation, it doesn't provide anything from what I am looking for:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff548055(v=vs.85).aspx
I could always run the !address command and have its output parsed, but I was looking for a cleaner way where I could get this information directly, by using the API.
Am I missing something? Is there a documented/undocumented way I could achieve this with?

Doesnt QueryVirtual Work ?
#include <engextcpp.hpp>
class EXT_CLASS : public ExtExtension
{
public:
EXT_COMMAND_METHOD(getoffinfo);
};
EXT_DECLARE_GLOBALS();
EXT_COMMAND( getoffinfo, "", "{;e,d=0;getoffinfo;simulates !address <address>}" )
{
ULONG64 Offset = GetUnnamedArgU64(0);
if (Offset == 0)
{
Out( "usage !getoffinfo <address>\n");
}
else
{
MEMORY_BASIC_INFORMATION64 meminfo;
memset(&meminfo,0,sizeof(MEMORY_BASIC_INFORMATION64 ));
m_Data2->QueryVirtual(Offset,&meminfo);
Out("Allocation Base : %x\n",meminfo.AllocationBase);
Out("Base Address : %x\n",meminfo.BaseAddress);
Out("End Address : %x\n",meminfo.AllocationBase + meminfo.RegionSize);
Out("RegionSize : %x\n",meminfo.RegionSize);
Out("Type : %x\n",meminfo.Type);
Out("State : %x\n",meminfo.State);
}
}
result as follows
0:000> !address windbg
Usage: Image
Allocation Base: 01000000
Base Address: 01000000
End Address: 01001000
Region Size: 00001000
Type: 01000000 MEM_IMAGE
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
More info: lmv m windbg
More info: !lmi windbg
More info: ln 0x1000000
0:000> .load getoffinfo
0:000> !getoffinfo
usage !getoffinfo <address>
0:000> !getoffinfo windbg
Allocation Base : 1000000
Base Address : 1000000
End Address : 1001000
RegionSize : 1000
Type : 1000000
State : 1000

Related

What "deleted" means in /proc/$pid/maps?

I downloaded libhugetlbfs.so and have a simple test source :
int glbarr[1024*1024]={0} ;
int main()
{
char * ptr ;
ptr = (char *) malloc( 1024 * 1024 * 1 ) ;
printf(" press any key to go on \n");
getchar() ;
for(int idx=0;idx<100;idx++){
char strtmp[64] = {0} ;
sprintf(strtmp,"%020d",idx) ;
strcpy( ptr+1024*idx , strtmp ) ;
} //for
for(int idx=0;idx<100;idx++){
glbarr[idx] = idx ;
}
printf(" press any key to go on \n");
getchar() ;
} // main
then set the env :
export LD_PRELOAD=libhugetlbfs.so
export HUGETLB_MORECORE=yes
export HUGETLB_DEBUG=1
At last , execute test_malloc.exe :
INFO: Found pagesize 2048 kB
INFO: Detected page sizes:
INFO: Size: 2048 kB (default) Mount: /mnt/SharedMem_2M
INFO: Parsed kernel version: [3] . [10] . [0]
INFO: Feature private_reservations is present in this kernel
INFO: Feature noreserve_safe is present in this kernel
INFO: Feature map_hugetlb is present in this kernel
INFO: Kernel has MAP_PRIVATE reservations. Disabling heap prefaulting.
INFO: Kernel supports MAP_HUGETLB
INFO: HUGETLB_SHARE=0, sharing disabled
INFO: HUGETLB_NO_RESERVE=no, reservations enabled
INFO: Segment 0 (phdr 2): 0x400000-0x400a04 (filesz=0xa04) (prot = 0x5)
INFO: Segment 1 (phdr 3): 0x600de0-0xa01080 (filesz=0x274) (prot = 0x3)
DEBUG: symbol to copy at 0x601060: stdin
DEBUG: Total memsz = 0x400ca4, memsz of largest segment = 0x4002a0
INFO: libhugetlbfs version: 2.20
INFO: Mapped hugeseg at 0x2aaaaac00000. Copying 0xa04 bytes and 0 extra bytes from 0x400000...done
INFO: Prepare succeeded
INFO: Mapped hugeseg at 0x2aaaaac00000. Copying 0x274 bytes and 0x14 extra bytes from 0x600de0...done
INFO: Prepare succeeded
INFO: setup_morecore(): heapaddr = 0x1c00000
INFO: hugetlbfs_morecore(2101248) = ...
INFO: heapbase = 0x1c00000, heaptop = 0x1c00000, mapsize = 0, delta=2101248
INFO: Attempting to map 4194304 bytes
INFO: ... = 0x1c00000
INFO: hugetlbfs_morecore(0) = ...
INFO: heapbase = 0x1c00000, heaptop = 0x1e01000, mapsize = 400000, delta=-2093056
INFO: ... = 0x1e01000
and the /proc/pidof test_malloc.exe/maps :
00400000-00600000 r-xp 00000000 00:2b 6019488 /mnt/SharedMem_2M/libhugetlbfs.tmp.uI55WD (deleted)
00600000-00c00000 rw-p 00000000 00:2b 6123885 /mnt/SharedMem_2M/libhugetlbfs.tmp.VUALYM (deleted)
01c00000-02000000 rw-p 00000000 00:0d 6123886 /anon_hugepage (deleted)
numastat -m showes hugepage really in use for 8M ,
What bother me is what do "deleted" means in maps output ?!
either in /mnt/SharedMem_2M or /anon_hugepage
Edit :
and the debug information :
INFO: Found pagesize 2048 kB
INFO: Detected page sizes:
INFO: Size: 2048 kB (default) Mount: /mnt/SharedMem_2M
INFO: Parsed kernel version: [3] . [10] . [0]
INFO: Feature private_reservations is present in this kernel
INFO: Feature noreserve_safe is present in this kernel
INFO: Feature map_hugetlb is present in this kernel
INFO: Kernel has MAP_PRIVATE reservations. Disabling heap prefaulting.
INFO: Kernel supports MAP_HUGETLB
INFO: HUGETLB_SHARE=0, sharing disabled
INFO: HUGETLB_NO_RESERVE=no, reservations enabled
INFO: Segment 0 (phdr 3): 0x600de0-0xa01080 (filesz=0x274) (prot = 0x3)
DEBUG: symbol to copy at 0x601060: stdin
DEBUG: Total memsz = 0x4002a0, memsz of largest segment = 0x4002a0
INFO: libhugetlbfs version: 2.20
INFO: Mapped hugeseg at 0x2aaaaac00000. Copying 0x274 bytes and 0x14 extra bytes from 0x600de0...done
INFO: Prepare succeeded
INFO: setup_morecore(): heapaddr = 0x2200000
INFO: hugetlbfs_morecore(2101248) = ...
INFO: heapbase = 0x2200000, heaptop = 0x2200000, mapsize = 0, delta=2101248
INFO: Attempting to map 4194304 bytes
INFO: ... = 0x2200000
INFO: hugetlbfs_morecore(0) = ...
INFO: heapbase = 0x2200000, heaptop = 0x2401000, mapsize = 400000, delta=-2093056
INFO: ... = 0x2401000
and the maps :
00400000 default file=/home/marschen/test/posix-memalign/test_malloc.exe mapped=1 N0=1 kernelpagesize_kB=4
00600000 default file=/mnt/SharedMem_2M/libhugetlbfs.tmp.85Y41e\040(deleted) huge anon=1 dirty=1 N0=1 kernelpagesize_kB=2048
02200000 default file=/anon_hugepage\040(deleted) huge anon=1 dirty=1 N0=1 kernelpagesize_kB=2048
Temporary file deletion (unlinking) is normal for libhugetlbfs when it uses hugetlb fs pseudo filesystem (grep hugetlbfs /proc/filesystems) for getting mmaps backed with hugetlb pages.
For example, there is hugetlbfs_unlinked_fd function of libhugetlbfs/hugeutils.c
https://github.com/libhugetlbfs/libhugetlbfs/blob/e44180072b796c0e28e53c4d01ef6279caaa2a99/hugeutils.c#L1033
int hugetlbfs_unlinked_fd_for_size(long page_size)
{
const char *path;
char name[PATH_MAX+1];
int fd;
path = hugetlbfs_find_path_for_size(page_size);
..
name[sizeof(name)-1] = '\0';
strcpy(name, path);
strncat(name, "/libhugetlbfs.tmp.XXXXXX", sizeof(name)-1);
/* FIXME: deal with overflows */
fd = mkstemp64(name);
....
unlink(name);
return fd;
}
Temporary file name is randomly generated in mkstemp function; it also creates the file and opens it. Then this file is unlinked (man 2 unlink) from the filesystem (file name is marked as deleted in the directory, there is still inode and file data, but other programs can't access this file by name).
While unlinked fd is opened, it can be used to work with hugetlb mmap and to store data. Only when this fd is closed, file data will be actually deleted by fs.
Early unlinking of mktemp files is often used: When a file created with mkstemp() is deleted?
Some useful information can be also listed in HOWTO of libhugetlbfs project
https://github.com/libhugetlbfs/libhugetlbfs/blob/master/HOWTO

Kernel address poising by clearing upper bits?

Is there some mechanism in Linux which is poisoning addresses by zeroing upper 16 bits?
I am debugging a kernel crash on an Intel x86-64 machine. The instruction which is causing the crash tries to access an address of 0x880139f3da00:
crash> bt
R10: 0000000000000001 R11: 0000000000000001 R12: 0000880139f3da00
~~~~~~~~~~~~~~~~~~~~~
crash> p arp_tbl.nht->hash_buckets[255]
$66 = (struct neighbour *) 0x880139f3da00
crash> p *arp_tbl.nht->hash_buckets[255]
Cannot access memory at address 0x880139f3da00
The hash_buckets table is valid:
crash> p arp_tbl.nht->hash_buckets[253]
$70 = (struct neighbour *) 0xffff88007325ae00
$71 = {
next = 0x0,
tbl = 0xffffffff81abbf20 <arp_tbl>,
Setting upper word to 0xffff makes the address valid and returns a valid data structure:
crash> p *((struct neighbour *)0xffff880139f3da00)
$73 = {
next = 0xffff88006de69a00,
tbl = 0xffffffff81abbf20 <arp_tbl>,
... rest looks reasonable too ...
Structure is updated by RCU operations (e.g. very likely by these in neigh_flush_dev()). So, what could be the reason that the address becomes invalid in such a way?
I can exclude hardware defects (seen on two machines and with different addresses). Systems are running CentOS 7 with kernel 3.10.0-514.6.1.el7.centos.plus.x86_64 till 3.10.0-514.21.2.el7.centos.plus.x86_64.
Update
From another crash dump, I see an skb of an IPv6 packet with
crash> p *((struct sk_buff *)0xffff880070e25e00)
$57 = {
transport_header = 54,
network_header = 14,
mac_header = 0,
...
head = 0xffff880138e28000 "",
data = 0xffff880138e2800e "`",
...
}
This crashes when writing the first 0x8 bytes in
#define HH_DATA_MOD 16
static inline int neigh_hh_output(const struct hh_cache *hh, struct sk_buff *skb)
{
if (likely(hh_len <= HH_DATA_MOD)) {
memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD); <<<<<
This would explain why two bytes are overridden (16 - 14).
can you inspect the memory location this address was read from? typically such a "partial zero" read is a result of memset being run on the area. after this cpu triggered a crash there was possibly enough time for whoever else was modifying the area to finish zeroing and possibly even fill it with other data.
so far there is no reason to suspect rcu plays any role here
this is most definitely not "poisoning" done by the kernel (it would be quite weird to do it in this way). however, if the crash is reproducible (you say it occurred on at least 2 different machines?) then running a debug kernel may be of help, especially with slab debug enabled.

walkup page tables on ARM

I'm trying to emulate the function lookup_address(http://lxr.free-electrons.com/source/arch/x86/mm/pageattr.c#L373) for arm platform (and just for kernel pagetables).
The point is I'm getting the address of swapper_pg_dir from TTBR1, and so far that's working.
I checked it with gdb:
(gdb) file vmlinux
Reading symbols from vmlinux...done.
(gdb) p init_mm.pgd
$1 = (pgd_t *) 0xc0004000
(gdb)
and the code from my module:
static pgd_t *get_global_pgd (void)
{
pgd_t *pgd;
unsigned int ttb_reg;
asm volatile (
" mrc p15, 0, %0, c2, c0, 1"
: "=r" (ttb_reg));
ttb_reg &= TTBR_MASK;
pgd = __va (ttb_reg);
pr_info ("get_global_pgd: %p\n", pgd);
return pgd;
}
and the output:
bananapi kernel: [ 5665.358139] mod: get_global_pgd: c0004000
So far, this is matching.
Now I'm computing the addr of the right pgd, doing:
pgd = get_global_pgd() + pgd_index (addr);
And since (addr >> 21) is 0x600, I get 0xc0007000.
Then I continue with:
pud = pud_offset (pgd, addr);
pr_info ("pud: 0x%0x - %p\n",pud_val (*pud), pud);
pmd = pmd_offset (pud, addr);
pr_info ("pmd: 0x%0x - %p\n", pmd_val (*pmd), pmd);
if (pmd == NULL || pmd_none (*pmd)) {
return NULL;
}
return pte_offset_kernel (pmd, addr);
output:
bananapi kernel: [ 5665.390391] mod: pud: 0x4001140e - c0007000
bananapi kernel: [ 5665.401603] mod: pmd: 0x4001140e - c0007000
bananapi kernel: [ 5665.423838] mod: pte: 0xe59f119c - c0011020
The problem is that the pte I get seems not to be fine, because the attributes of the pte don't match.
Let's take an address from /proc/kallsyms:
c0008054 t __create_page_tables
I can read it with gdb:
(gdb) x/2x 0xc0008054
0xc0008054 <__create_page_tables>: 0xe2884901 0xe1a00004
(gdb)
But the pte I get from this address, doesn't have the present flag:
I'm checking it with (this pte is the one I got from my lookup_address):
ret = pte_present (*pte);
pr_info ("pte_present: %d\n", ret);
The pte_present is 0 (which checks L_PTE_PRESENT flag defined include/asm/pgtable-2level.h), but shoudln't be 0 as long as I can read from it in GDB.
I've tested with some other addresses, for instance: 0xc0035618:
c0035618 T __put_task_struct
And for this one the L_PTE_PRESENT big is set.
I'm pretty sure I'm missing something, or I got it wrong.
Thanks in advance!
I've read all the pointed links, but I'm afraig I still don't get the whole picture.
I'll try to explain what I understood so far:
From include/asm/pgtable-2level.h , it looks like a page stores:
0 - pte1_linux
1024 - pte2_linux
2048 - pte1_hw
3072 - pte2_hw
Actually I also saw this in early_pte_alloc function, which allocates 4096bytes for the pte:
static pte_t * __init early_pte_alloc(pmd_t *pmd, unsigned long addr, unsigned long prot)
{
if (pmd_none(*pmd)) {
pte_t *pte = early_alloc(PTE_HWTABLE_OFF + PTE_HWTABLE_SIZE);
__pmd_populate(pmd, __pa(pte), prot);
}
BUG_ON(pmd_bad(*pmd));
return pte_offset_kernel(pmd, addr);
}
Then, in __pmd_populate we take the phys address of the memory previously allocated, we add 2048 (for hw pte), and we OR it with the protection flag (which in case to be from a kernel_domain should be PMD_TYPE_TABLE.
static inline void __pmd_populate(pmd_t *pmdp, phys_addr_t pte,
pmdval_t prot)
{
pmdval_t pmdval = (pte + PTE_HWTABLE_OFF) | prot;
pmdp[0] = __pmd(pmdval);
#ifndef CONFIG_ARM_LPAE
pmdp[1] = __pmd(pmdval + 256 * sizeof(pte_t));
#endif
flush_pmd_entry(pmdp);
}
So far is clear.
Given this information, a walking page should be something like:
pmd_offset_k (addr)
pud_offset (pgd, addr)
pmd_offset (pud, addr)
pte_offset_kernel (pmd, addr)
pte_offset_kernel gives the virtual address of the pmd_val stored in pmd. (it also ANDs the value with PHYS_MASK and PAGE_MASK), and adds the pte_index (addr).
At this point I should have the value of the virtual addres of the linux_pte_0 (because the previous ANDs with PAGE_MASK brought me to the top of the page).
So I think at this point I should be able to check the L_PTE_* flags.
Am I wrong?
Thanks in advance

Dump All VAD of a process in Windows

I wanna get some memory dump of a specific process.
I've found each windows process contain VadRoot in a EPROCESS.
I used windbg to get some information of this structure...
kd> dt nt!_MMVAD fffffa801b7011d0
+0x000 u1 : <unnamed-tag>
+0x008 LeftChild : (null)
+0x010 RightChild : (null)
+0x018 StartingVpn : 0x7fefe440
+0x020 EndingVpn : 0x7fefe4b0
+0x028 u : <unnamed-tag>
+0x030 PushLock : _EX_PUSH_LOCK
+0x038 u5 : <unnamed-tag>
+0x040 u2 : <unnamed-tag>
+0x048 Subsection : 0xfffffa80`19f62640 _SUBSECTION
+0x048 MappedSubsection : 0xfffffa80`19f62640 _MSUBSECTION
+0x050 FirstPrototypePte : 0xfffff8a0`00b3ac28 _MMPTE
+0x058 LastContiguousPte : 0xffffffff`fffffffc _MMPTE
+0x060 ViewLinks : _LIST_ENTRY [ 0xfffffa80`1b7a38c0 - 0xfffffa80`1aa6d6a0 ]
+0x070 VadsProcess : 0xfffffa80`1b7e8941 _EPROCESS
Its Win7 64bit.
I guess StartingVpn: 0x7fefe440 has contain the memory contents of this block.
But is that a virtual address? or physical address? i don't know
what it stands for...
Thanks.
locate process
lkd> !process 0 0 explorer.exe
PROCESS 8a1908d0 ...... Image: explorer.exe
set process context
lkd> .process /p /r 8a1908d0
view reqd module
lkd> lm m explorer
start end module name
01000000 010ff000 Explorer (deferred)
get the vadroot for a virtual address in the current process context
lkd> !vad explorer 1
VAD # 8a120ed0
Start VPN 1000 End VPN 10fe Control Area 8a81ab80
FirstProtoPte e23e9048 LastPte fffffffc Commit Charge 3 (3.)
Secured.Flink 0 Blink 0 Banked/Extend 0
File Offset 0
ImageMap ViewShare EXECUTE_WRITECOPY
ReadOnly
ControlArea # 8a81ab80
Segment e23e9008 Flink 00000000 Blink 00000000
Section Ref 1 Pfn Ref 4d Mapped Views 1
User Ref 2 WaitForDel 0 Flush Count 0
File Object 8ab28240 ModWriteCount 0 System Views 0
Flags (90000a0) Image File HadUserReference Accessed
\WINDOWS\explorer.exe
Segment # e23e9008
ControlArea 8a81ab80 BasedAddress 01000000
Total Ptes ff
WriteUserRef 0 SizeOfSegment ff000
Committed 0 PTE Template 8a81ac3000000420
Based Addr 1000000 Image Base 0
Image Commit 2 Image Info e23e9840
ProtoPtes e23e9048
Reload command: .reload explorer.exe=01000000,ff000
dump all the vads for a current process context
lkd> !vad 8a120ed0 0
VAD level start end commit
8a03b1d8 ( 3) e50 e51 0 Mapped READONLY Pagefile-backed section
8a6fe240 ( 4) e60 e6f 0 Mapped READWRITE Pagefile-backed section
................................
89c86600 ( 5) ff0 ff0 1 Private READWRITE
8a120ed0 ( 0) 1000 10fe 3 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\explorer.exe
.................................
8a87bb18 ( 7) 26d0 2733 0 Mapped READWRITE \Documents and Settings\Admin\Local Settings\History\History.IE5\index.dat
8a74b420 ( 0) 3e1c0 3ec52 10 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ieframe.dll
8abfa398 ( 1) 7ffde 7ffde 1 Private READWRITE
Total VADs: 1231, average level: 5, maximum depth: 4294967295
VAD is short for virtual address descriptor and VPN is short for virtual page number. So it's a virtual address, not a physical address.
It needs to be translated to a physical address using PTEs (page table entry).
Given a user mode address I found with a user mode debugging session:
0:032> !address
[...]
+ 7ff`fffdc000 7ff`fffde000 0`00002000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE TEB [~1; 13ec.10fc]
0:032> dd 7ff`fffde000 L8
000007ff`fffde000 00000000 00000000 00240000 00000000
000007ff`fffde010 0022b000 00000000 00000000 00000000
I can do this in a kernel debugging session using LiveKd (SysInternals):
0: kd> !process 0 0 explorer.exe
PROCESS fffffa8012ce5b10
SessionId: 1 Cid: 13ec Peb: 7fffffd6000 ParentCid: 13c0
DirBase: 3029e8000 ObjectTable: fffff8a006139d60 HandleCount: 1078.
Image: explorer.exe
0: kd> .process /p /r fffffa8012ce5b10
Implicit process is now fffffa80`12ce5b10
Loading User Symbols
[...]
0: kd> !vtop 0 7fffffde000
Amd64VtoP: Virt 000007ff`fffde000, pagedir 00000003`029e8000
Amd64VtoP: PML4E 00000003`029e8078
Amd64VtoP: PDPE 00000003`00ebcff8
Amd64VtoP: PDE 00000003`0203dff8
Amd64VtoP: PTE 00000003`01ebeef0
Amd64VtoP: Mapped phys 00000002`ff44f000
Virtual address 7fffffde000 translates to physical address 2ff44f000.
0: kd> dd /p 2ff44f000 L8
00000002`ff44f000 00000000 00000000 00240000 00000000
00000002`ff44f010 0022b000 00000000 00000000 00000000
Note how the content of the virtual address (dd) is identical to the physical address (dd /p).

linux driver, port 2.6.19.2 - 2.6.38-rc2 ARM11 iMX31, amba MBX device LogicPD Litekit GLES driver

Code followed with question
#define MBX_REG_SYS_PHYS_BASE 0xC0000000
#define MBX_REG_RANGE 0x00004000
static struct resource mxc_reg_resources[] = {
{
.start = MBX_REG_SYS_PHYS_BASE,
.end = MBX_REG_SYS_PHYS_BASE + MBX_REG_RANGE - 1,
.flags = IORESOURCE_MEM }
};
mbx_reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mbx_reg)
return -EINVAL;
reg_base = ioremap(mbx_reg->start, resource_size(mbx_reg));
if (!reg_base) {
ret = -ENOMEM;
goto eremap;
}
printk(KERN_CRIT "Address: from 0x%08X to 0x%08X\n",
mbx_reg->start, reg_base);
regread = mx3reg_read_reg(mx3reg, MBX1_GLOBREG_REVISION);
printk(KERN_CRIT "MBX1_GLOBREG_REVISION: 0x%.8X\n", regread);
This code works on iMX31 from LogicPD using 2.6.19.2 with out of tree patching from freescale.
when porting it to 2.6.38-rc2 it no longer works.
here are some data results:
Working results:
Address: 0xC7860000
MBX1_GLOBREG_REVISION: 0x01010200
Failed results:
Address: 0xC48A0000
MBX1_GLOBREG_REVISION: 0x00000000
Address: 0xC48A8000
MBX1_GLOBREG_REVISION: 0x00000000
Address: 0xC48B8000
MBX1_GLOBREG_REVISION: 0x00000000
Address: 0xC48C0000
MBX1_GLOBREG_REVISION: 0x00000000
maybe interesting is on 2.6.19.2 it always gets the same address mapped
yet in 2.6.38-rc2 it does not.
Are you sure your defines are still good ? The output for this line should not change :
printk(KERN_CRIT "Address: from 0x%08X to 0x%08X\n",
mbx_reg->start, reg_base);
Since it is a physical address. However it is not printed in your output.
Check the pripheral you are accessing is clocked.
In order to have this device ready to communicate you need to setup the peripheral port remap register
/* Setup Peripheral Port Remap register for AVIC */
asm("ldr r0, =0xC0000015 \n\
mcr p15, 0, r0, c15, c2, 4");
here is the code from the original 2.6.19.2 kernel, executed from a board fixup routine.
and of course the clocks would have to be enabled as well, and this driver example is not showing that either.

Resources