FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 02-13-2012, 05:54 AM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

The following series implements :

* An infrastructure for platform based vmalloc translation for PPC32
* vmalloc translation support for PPC44x

Changes since V2:

* Rebased to crash-6.0.3
* Maintains a list of probe functions, rather than platform
definitions.


Each platform can define their own probe_function which would get the name of the
ppc platform (read from kernel) and the probe can check if the platform is one of its
variant. The probe function can then update the 'platform' defintions for the virtual
address translation.

If none of the defined platforms match, falls back to using the default PPC32
definitions.

---

Suzuki K. Poulose (3):
[ppc] virtual address translation bits for PPC44x
[ppc] Support for platform based Virtual address translation
[ppc] Non-linear address translation routine


defs.h | 19 ++++
ppc.c | 282 +++++++++++++++++++++++++++++++++++++---------------------------
2 files changed, 178 insertions(+), 123 deletions(-)

--
Suzuki Poulose

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-15-2012, 07:58 AM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

On 02/15/2012 10:56 AM, Suzuki K. Poulose wrote:

On 02/13/2012 10:17 PM, Dave Anderson wrote:


----- Original Message -----

The following series implements :

* An infrastructure for platform based vmalloc translation for PPC32
* vmalloc translation support for PPC44x

Changes since V2:

* Rebased to crash-6.0.3
* Maintains a list of probe functions, rather than platform
definitions.


Each platform can define their own probe_function which would get the name of the
ppc platform (read from kernel) and the probe can check if the platform is one of its
variant. The probe function can then update the 'platform' defintions for the virtual
address translation.

If none of the defined platforms match, falls back to using the default PPC32
definitions.

---

Suzuki K. Poulose (3):
[ppc] virtual address translation bits for PPC44x
[ppc] Support for platform based Virtual address translation
[ppc] Non-linear address translation routine


Hi Suzuki,

I'll defer the technical ACK to Toshi, but I do have a couple of other suggestions.

Here's a sample vmalloc translation:

crash> vtop d1180000
VIRTUAL PHYSICAL
d1180000 ff800000

Using ppc440gp board definitions:
PAGE DIRECTORY: c056f000
PGD: c0570a20 => c784b000
PMD: c784b000 => c784bc00
PTE: c784bc00 => 1ff80051b
PAGE: ff800000

PTE PHYSICAL FLAGS
ff80051b ff800000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
crash>

This may have been a pre-existing issue, but for vmalloc addresses, the
page struct translation at the end of the display (under PAGE PHYSICAL MAPPING...)
is missing for vmalloc addresses. For user-space and unity-mapped
addresses the translation is done as intended:

User-space:

crash> vtop ff8f000
VIRTUAL PHYSICAL
ff8f000 6b90000

Using ppc440gp board definitions:
PAGE DIRECTORY: c7a3a000
PGD: c7a3a1fc => c7bfc000
PMD: c7bfc000 => c7bfcc78
PTE: c7bfcc78 => 6b9005b
PAGE: 6b90000

PTE PHYSICAL FLAGS
6b9005b 6b90000 (PRESENT|USER|GUARDED|COHERENT|WRITETHRU)

VMA START END FLAGS FILE
c7b09898 ff8f000 ff92000 100073

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c06b5200 6b90000 c7a9fc61 ff8f 1 80068
crash>

Kernel unity-mapped:

crash> vtop c7b14000
VIRTUAL PHYSICAL
c7b14000 7b14000

Using ppc440gp board definitions:
PAGE DIRECTORY: c056f000
PGD: c05708f4 => 0

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c06d4280 7b14000 0 0 1 0
crash>

That should be a trivial fix.


I took a look at the above issue of vtop report and here is what
I find :

crash> p *vmlist
$17 = {
next = 0xc784e880,
addr = 0xd1002000,
size = 8192,
flags = 1,
pages = 0x0,
nr_pages = 0,
phys_addr = 8837398528,
caller = 0xc042bf40
}
crash> vtop 0xd1002000
VIRTUAL PHYSICAL
d1002000 ec00000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b010
PTE: c784b010 => 20ec0051b
PAGE: ec00000

PTE PHYSICAL FLAGS
ec0051b ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS

crash> x /i vmlist->caller
0xc042bf40 <setup_indirect_pci+84>: blr

Here, the total amount for RAM on the machine is 128M and looks like
the above address is memory mapped PCI bus, which lies above the 128M.
Also note that the number of pages is '0'. Since the page lies above the
128M and the number of pages is 0, the dump_mem_map fails to find the page struct
for the corresponding phsyical address.

If we go further in the vmlist to find the vmalloc address pages that have pages,
we get :

crash> p *(vmlist->next->next->next)
$16 = {
next = 0xc78e51c0,
addr = 0xd1008000,
size = 8192,
flags = 2,
pages = 0xc7891680,
nr_pages = 1,
phys_addr = 0,
caller = 0xc006a1d0
}
crash> vtop 0xd1008000
VIRTUAL PHYSICAL
d1008000 7896000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b040
PTE: c784b040 => 789601f
PAGE: 7896000

PTE PHYSICAL FLAGS
789601f 7896000 (PRESENT|USER|RW|GUARDED|COHERENT)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c06d72c0 7896000 0 0 1 0

So, may be we could add a check in the vmalloc translation to see if there is really
a page allocated for the block and then do the translation of the pages.


I have a patch which could do something like:


crash> vtop d1002000
VIRTUAL PHYSICAL
d1002000 20ec00000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b010
PTE: c784b010 => 20ec0051b
PAGE: 20ec00000

PTE PHYSICAL FLAGS
20ec0051b 20ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED)

The memory 0x20ec00000 doesn't have a PFN associated with it.
It could be an MMIO region above the RAM(128 MB).
crash>



Thanks

Suzuki

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-16-2012, 10:33 AM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

On 02/15/2012 08:49 PM, Dave Anderson wrote:



----- Original Message -----

On 02/15/2012 10:56 AM, Suzuki K. Poulose wrote:

On 02/13/2012 10:17 PM, Dave Anderson wrote:


----- Original Message -----

The following series implements :

* An infrastructure for platform based vmalloc translation for
PPC32
* vmalloc translation support for PPC44x

Changes since V2:

* Rebased to crash-6.0.3
* Maintains a list of probe functions, rather than platform
definitions.


Each platform can define their own probe_function which would get
the name of the
ppc platform (read from kernel) and the probe can check if the
platform is one of its
variant. The probe function can then update the 'platform'
defintions for the virtual
address translation.

If none of the defined platforms match, falls back to using the
default PPC32
definitions.

---

Suzuki K. Poulose (3):
[ppc] virtual address translation bits for PPC44x
[ppc] Support for platform based Virtual address translation
[ppc] Non-linear address translation routine


Hi Suzuki,

I'll defer the technical ACK to Toshi, but I do have a couple of
other suggestions.

Here's a sample vmalloc translation:

crash> vtop d1180000
VIRTUAL PHYSICAL
d1180000 ff800000

Using ppc440gp board definitions:
PAGE DIRECTORY: c056f000
PGD: c0570a20 => c784b000
PMD: c784b000 => c784bc00
PTE: c784bc00 => 1ff80051b
PAGE: ff800000

PTE PHYSICAL FLAGS
ff80051b ff800000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
crash>

This may have been a pre-existing issue, but for vmalloc
addresses, the
page struct translation at the end of the display (under PAGE
PHYSICAL MAPPING...)
is missing for vmalloc addresses. For user-space and unity-mapped
addresses the translation is done as intended:

User-space:

crash> vtop ff8f000
VIRTUAL PHYSICAL
ff8f000 6b90000

Using ppc440gp board definitions:
PAGE DIRECTORY: c7a3a000
PGD: c7a3a1fc => c7bfc000
PMD: c7bfc000 => c7bfcc78
PTE: c7bfcc78 => 6b9005b
PAGE: 6b90000

PTE PHYSICAL FLAGS
6b9005b 6b90000 (PRESENT|USER|GUARDED|COHERENT|WRITETHRU)

VMA START END FLAGS FILE
c7b09898 ff8f000 ff92000 100073

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c06b5200 6b90000 c7a9fc61 ff8f 1 80068
crash>

Kernel unity-mapped:

crash> vtop c7b14000
VIRTUAL PHYSICAL
c7b14000 7b14000

Using ppc440gp board definitions:
PAGE DIRECTORY: c056f000
PGD: c05708f4 => 0

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c06d4280 7b14000 0 0 1 0
crash>

That should be a trivial fix.


I took a look at the above issue of vtop report and here is what
I find :

crash> p *vmlist
$17 = {
next = 0xc784e880,
addr = 0xd1002000,
size = 8192,
flags = 1,
pages = 0x0,
nr_pages = 0,
phys_addr = 8837398528,
caller = 0xc042bf40
}
crash> vtop 0xd1002000
VIRTUAL PHYSICAL
d1002000 ec00000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b010
PTE: c784b010 => 20ec0051b
PAGE: ec00000

PTE PHYSICAL FLAGS
ec0051b ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS

crash> x /i vmlist->caller
0xc042bf40<setup_indirect_pci+84>: blr

Here, the total amount for RAM on the machine is 128M and looks like
the above address is memory mapped PCI bus, which lies above the 128M.
Also note that the number of pages is '0'. Since the page lies above the
128M and the number of pages is 0, the dump_mem_map fails to find the page struct
for the corresponding phsyical address.

If we go further in the vmlist to find the vmalloc address pages that have pages,
we get :

crash> p *(vmlist->next->next->next)
$16 = {
next = 0xc78e51c0,
addr = 0xd1008000,
size = 8192,
flags = 2,
pages = 0xc7891680,
nr_pages = 1,
phys_addr = 0,
caller = 0xc006a1d0
}
crash> vtop 0xd1008000
VIRTUAL PHYSICAL
d1008000 7896000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b040
PTE: c784b040 => 789601f
PAGE: 7896000

PTE PHYSICAL FLAGS
789601f 7896000 (PRESENT|USER|RW|GUARDED|COHERENT)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c06d72c0 7896000 0 0 1 0

So, may be we could add a check in the vmalloc translation to see if there is really
a page allocated for the block and then do the translation of the pages.


I have a patch which could do something like:

crash> vtop d1002000
VIRTUAL PHYSICAL
d1002000 20ec00000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b010
PTE: c784b010 => 20ec0051b
PAGE: 20ec00000

PTE PHYSICAL FLAGS
20ec0051b 20ec00000 (PRESENT|USER|GUARDED|COHERENT|ACCESSED)

The memory 0x20ec00000 doesn't have a PFN associated with it.
It could be an MMIO region above the RAM(128 MB).
crash>


Ah yes, I'm sorry Suzuike -- I forgot that can be seen on any
architecture.

Taking x86_64 as an example, it's seen by just looking at the
first two entries on the vmlist:

crash> kmem -v
VM_STRUCT ADDRESS RANGE SIZE
ffff88003f824f00 ffffc90000000000 - ffffc90000002000 8192
ffff88003f824a00 ffffc90000003000 - ffffc90000104000 1052672
... [ cut ] ...

The second vm_struct in the vmlist at ffff88003f824a00 shows
that there are 256 pages associated with it:

crash> vm_struct ffff88003f824a00
struct vm_struct {
next = 0xffff88003f824980,
addr = 0xffffc90000003000,
size = 1052672,
flags = 2,
pages = 0xffff88003fae7000,
nr_pages = 256,
phys_addr = 0,
caller = 0xffffffff818e426c
}
crash>

and so for any vmalloc address within it, the page translation is
displayed by vtop:

crash> vtop ffffc90000003000
VIRTUAL PHYSICAL
ffffc90000003000 3faed000

PML4 DIRECTORY: ffffffff81001000
PAGE DIRECTORY: 3faa5067
PUD: 3faa5000 => 3faa6067
PMD: 3faa6000 => 3faa7067
PTE: 3faa7018 => 800000003faed163
PAGE: 3faed000

PTE PHYSICAL FLAGS
800000003faed163 3faed000 (PRESENT|RW|ACCESSED|DIRTY|GLOBAL|NX)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0000dee3d8 3faed000 0 0 1 20000000000000
crash>

But the first entry in the vmlist at ffff88003f824f00 does not have
any pages:

crash> kmem -v
VM_STRUCT ADDRESS RANGE SIZE
ffff88003f824f00 ffffc90000000000 - ffffc90000002000 8192
ffff88003f824a00 ffffc90000003000 - ffffc90000104000 1052672
... [ cut ] ...

crash> vm_struct ffff88003f824f00
struct vm_struct {
next = 0xffff88003f824a00,
addr = 0xffffc90000000000,
size = 8192,
flags = 1,
pages = 0x0,
nr_pages = 0,
phys_addr = 4275044352,
caller = 0xffffffff818d5a66
}

and so no page translation is shown:

crash> vtop ffffc90000000000
VIRTUAL PHYSICAL
ffffc90000000000 fed00000

PML4 DIRECTORY: ffffffff81001000
PAGE DIRECTORY: 3faa5067
PUD: 3faa5000 => 3faa6067
PMD: 3faa6000 => 3faa7067
PTE: 3faa7000 => 80000000fed00173
PAGE: fed00000

PTE PHYSICAL FLAGS
80000000fed00173 fed00000 (PRESENT|RW|PCD|ACCESSED|DIRTY|GLOBAL|NX)

crash>

So just do the same thing -- no verbose expanation is required.


There are two ways to fix this :

1) Fix dump_mem_map*() to print the header only when there is information to dump.

--- a/memory.c
+++ b/memory.c
@@ -4637,13 +4637,6 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
continue;
}

- if (print_hdr) {

- if (!(pc->curcmd_flags & HEADER_PRINTED))
- fprintf(fp, "%s", hdr);
- print_hdr = FALSE;
- pc->curcmd_flags |= HEADER_PRINTED;
- }
-
pp = section_mem_map_addr(section);
pp = sparse_decode_mem_map(pp, section_nr);
phys = (physaddr_t) section_nr * PAGES_PER_SECTION() * PAGESIZE();
@@ -4854,6 +4847,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex > buffersize) {

+ if (print_hdr) {
+ if (!(pc->curcmd_flags & HEADER_PRINTED))
+ fprintf(fp, "%s", hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |= HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
bufferindex = 0;
}
@@ -4867,6 +4867,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex > 0) {

+ if (print_hdr) {
+ if (!(pc->curcmd_flags & HEADER_PRINTED))
+ fprintf(fp, "%s", hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |= HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
}

Similarly for the dump_mem_map().

2) Fix ppc_pgd_vtop() to return FALSE if the paddr > machdep->memsize

--- a/ppc.c
+++ b/ppc.c
@@ -438,6 +438,10 @@ ppc_pgd_vtop(ulong *pgd, ulong vaddr, physaddr_t *paddr, int verbose)

*paddr = PAGEBASE(pte) + PAGEOFFSET(vaddr);

+ if (*paddr > machdep->memsize)

+ /* We don't have pages above System RAM */
+ return FALSE;
+
return TRUE;

no_page:


I prefer the (1). What do you think ?

Thanks
Suzuki

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-16-2012, 05:56 PM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

On 02/16/2012 09:52 PM, Dave Anderson wrote:



----- Original Message -----
...

So just do the same thing -- no verbose expanation is required.


There are two ways to fix this :

1) Fix dump_mem_map*() to print the header only when there is
information to dump.

--- a/memory.c
+++ b/memory.c
@@ -4637,13 +4637,6 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
continue;
}

- if (print_hdr) {
- if (!(pc->curcmd_flags& HEADER_PRINTED))
- fprintf(fp, "%s", hdr);
- print_hdr = FALSE;
- pc->curcmd_flags |= HEADER_PRINTED;
- }
-
pp = section_mem_map_addr(section);
pp = sparse_decode_mem_map(pp, section_nr);
phys = (physaddr_t) section_nr * PAGES_PER_SECTION()
* PAGESIZE();
@@ -4854,6 +4847,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex> buffersize) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags& HEADER_PRINTED))
+ fprintf(fp, "%s", hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |= HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
bufferindex = 0;
}
@@ -4867,6 +4867,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex> 0) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags& HEADER_PRINTED))
+ fprintf(fp, "%s", hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |= HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
}

Similarly for the dump_mem_map().

2) Fix ppc_pgd_vtop() to return FALSE if the paddr> machdep->memsize

--- a/ppc.c
+++ b/ppc.c
@@ -438,6 +438,10 @@ ppc_pgd_vtop(ulong *pgd, ulong vaddr, physaddr_t
*paddr, int verbose)

*paddr = PAGEBASE(pte) + PAGEOFFSET(vaddr);

+ if (*paddr> machdep->memsize)
+ /* We don't have pages above System RAM */
+ return FALSE;
+
return TRUE;

no_page:

I prefer the (1). What do you think ?


Hi Suzuki,

Hmmm -- with respect to (1), I suppose that would work, although
given that both x86 and x86_64 pass through dump_mem_map_SPARSEMEM()
without printing the header in a non-existent-page case, I don't
understand why ppc is different?

Yep, I digged into that a little, but not deep enough to debug it with
a dump. Nothing was evident from the code .



And I'm thinking that a more general solution might be to change
do_vtop() here, and not even bother calling the relevant dump_mem_map()
function if there's no page struct associated with it:

--- memory.c 10 Feb 2012 16:41:38 -0000 1.273
+++ memory.c 16 Feb 2012 14:18:03 -0000
@@ -2796,7 +2796,7 @@
do_vtop(ulong vaddr, struct task_context *tc, ulong vtop_flags)
{
physaddr_t paddr;
- ulong vma;
+ ulong vma, pageptr;
int page_exists;
struct meminfo meminfo;
char buf1[BUFSIZE];
@@ -2930,7 +2930,7 @@

fprintf(fp, "
");

- if (page_exists) {
+ if (page_exists&& phys_to_page(paddr,&pageptr)) {
if ((pc->flags& DEVMEM)&& (paddr>= VTOP(vt->high_memory)))
return;
BZERO(&meminfo, sizeof(struct meminfo));

And w/respect to (2), wouldn't that just cause the generic kvtop()
to fail? And if so, it kind of re-defines the meaning of kvtop(),
even though its current callers pretty much expect to receive
a legitimate physical memory address. But if a virtual address
resolves to a PTE with any legitimate address in it, then kvtop()
should return whatever's there.


Yep, I agree.



But I'm still wondering what makes ppc behave differently in
dump_mem_map_SPARSEMEM()?


Btw, we don't have SPARSMEM on ppc44x, and end up in dump_mem_map(). I was
patching both the functions to cover all the platforms.

Also, I found out that we need to abstract away the definition of Page flags
as well, since it differes for different platforms (except for the _PAGE_PRESENT).
I will include the changes in the next version.

Thanks
Suzuki

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-17-2012, 05:03 AM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

On 02/17/2012 12:43 AM, Dave Anderson wrote:



----- Original Message -----

On 02/16/2012 09:52 PM, Dave Anderson wrote:



----- Original Message -----
...

So just do the same thing -- no verbose expanation is required.


There are two ways to fix this :

1) Fix dump_mem_map*() to print the header only when there is
information to dump.

--- a/memory.c
+++ b/memory.c
@@ -4637,13 +4637,6 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
continue;
}

- if (print_hdr) {
- if (!(pc->curcmd_flags& HEADER_PRINTED))
- fprintf(fp, "%s", hdr);
- print_hdr = FALSE;
- pc->curcmd_flags |= HEADER_PRINTED;
- }
-
pp = section_mem_map_addr(section);
pp = sparse_decode_mem_map(pp, section_nr);
phys = (physaddr_t) section_nr *
PAGES_PER_SECTION()
* PAGESIZE();
@@ -4854,6 +4847,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex> buffersize) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags&
HEADER_PRINTED))
+ fprintf(fp, "%s",
hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |=
HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
bufferindex = 0;
}
@@ -4867,6 +4867,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex> 0) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags& HEADER_PRINTED))
+ fprintf(fp, "%s", hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |= HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
}

Similarly for the dump_mem_map().

2) Fix ppc_pgd_vtop() to return FALSE if the paddr>
machdep->memsize

--- a/ppc.c
+++ b/ppc.c
@@ -438,6 +438,10 @@ ppc_pgd_vtop(ulong *pgd, ulong vaddr,
physaddr_t
*paddr, int verbose)

*paddr = PAGEBASE(pte) + PAGEOFFSET(vaddr);

+ if (*paddr> machdep->memsize)
+ /* We don't have pages above System RAM */
+ return FALSE;
+
return TRUE;

no_page:

I prefer the (1). What do you think ?


Hi Suzuki,

Hmmm -- with respect to (1), I suppose that would work, although
given that both x86 and x86_64 pass through dump_mem_map_SPARSEMEM()
without printing the header in a non-existent-page case, I don't
understand why ppc is different?

Yep, I digged into that a little, but not deep enough to debug it with
a dump. Nothing was evident from the code .


Right -- I tried debugging it from the x86 and x86_64 perspective,
and couldn't see why ppc would be different! ;-)

Ah, well, I was talking about the x86_64 dump.
I could explain the PPC side of affairs :-). We have page the following
flags set for the page(with the actual PPC44x page flags support) :

VIRTUAL PHYSICAL
d1002000 20ec00000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b010
PTE: c784b010 => 20ec0051b
PAGE: 20ec00000

PTE PHYSICAL FLAGS
20ec0051b 20ec00000 (PRESENT|RW|GUARDED|NO_CACHE|DIRTY|ACCESSED)


So the page is 'present', but there is no page descriptor associated with it.
Hence dump_mem_map() would still be called and hence the problem.

Why doesn't it get called in x86_64 case even when the flags indicate page 'PRESENT' ?

Cheers
Suzuki

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-17-2012, 05:10 AM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

On 02/17/2012 12:43 AM, Dave Anderson wrote:



----- Original Message -----

On 02/16/2012 09:52 PM, Dave Anderson wrote:



----- Original Message -----
...

So just do the same thing -- no verbose expanation is required.


There are two ways to fix this :

1) Fix dump_mem_map*() to print the header only when there is
information to dump.

--- a/memory.c
+++ b/memory.c
@@ -4637,13 +4637,6 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
continue;
}

- if (print_hdr) {
- if (!(pc->curcmd_flags& HEADER_PRINTED))
- fprintf(fp, "%s", hdr);
- print_hdr = FALSE;
- pc->curcmd_flags |= HEADER_PRINTED;
- }
-
pp = section_mem_map_addr(section);
pp = sparse_decode_mem_map(pp, section_nr);
phys = (physaddr_t) section_nr *
PAGES_PER_SECTION()
* PAGESIZE();
@@ -4854,6 +4847,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex> buffersize) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags&
HEADER_PRINTED))
+ fprintf(fp, "%s",
hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |=
HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
bufferindex = 0;
}
@@ -4867,6 +4867,13 @@ dump_mem_map_SPARSEMEM(struct meminfo *mi)
}

if (bufferindex> 0) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags& HEADER_PRINTED))
+ fprintf(fp, "%s", hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |= HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
}

Similarly for the dump_mem_map().

2) Fix ppc_pgd_vtop() to return FALSE if the paddr>
machdep->memsize

--- a/ppc.c
+++ b/ppc.c
@@ -438,6 +438,10 @@ ppc_pgd_vtop(ulong *pgd, ulong vaddr,
physaddr_t
*paddr, int verbose)

*paddr = PAGEBASE(pte) + PAGEOFFSET(vaddr);

+ if (*paddr> machdep->memsize)
+ /* We don't have pages above System RAM */
+ return FALSE;
+
return TRUE;

no_page:

I prefer the (1). What do you think ?


Hi Suzuki,

Hmmm -- with respect to (1), I suppose that would work, although
given that both x86 and x86_64 pass through dump_mem_map_SPARSEMEM()
without printing the header in a non-existent-page case, I don't
understand why ppc is different?

Yep, I digged into that a little, but not deep enough to debug it with
a dump. Nothing was evident from the code .


Right -- I tried debugging it from the x86 and x86_64 perspective,
and couldn't see why ppc would be different! ;-)

Oh well...



And I'm thinking that a more general solution might be to change
do_vtop() here, and not even bother calling the relevant
dump_mem_map()
function if there's no page struct associated with it:

--- memory.c 10 Feb 2012 16:41:38 -0000 1.273
+++ memory.c 16 Feb 2012 14:18:03 -0000
@@ -2796,7 +2796,7 @@
do_vtop(ulong vaddr, struct task_context *tc, ulong vtop_flags)
{
physaddr_t paddr;
- ulong vma;
+ ulong vma, pageptr;
int page_exists;
struct meminfo meminfo;
char buf1[BUFSIZE];
@@ -2930,7 +2930,7 @@

fprintf(fp, "
");

- if (page_exists) {
+ if (page_exists&& phys_to_page(paddr,&pageptr)) {
if ((pc->flags& DEVMEM)&& (paddr>=
VTOP(vt->high_memory)))
return;
BZERO(&meminfo, sizeof(struct meminfo));

And w/respect to (2), wouldn't that just cause the generic kvtop()
to fail? And if so, it kind of re-defines the meaning of kvtop(),
even though its current callers pretty much expect to receive
a legitimate physical memory address. But if a virtual address
resolves to a PTE with any legitimate address in it, then kvtop()
should return whatever's there.


Yep, I agree.



But I'm still wondering what makes ppc behave differently in
dump_mem_map_SPARSEMEM()?


Btw, we don't have SPARSMEM on ppc44x, and end up in dump_mem_map(). I was
patching both the functions to cover all the platforms.


OK, so do you agree that just patching do_vtop() makes more sense?


Yep. One more question. Why don't we use phys_to_page() in the dump_mem_mapXX() to
get the page struct and then do the rest of the work ?


Thanks

Suzuki




Also, I found out that we need to abstract away the definition of Page flags
as well, since it differes for different platforms (except for the _PAGE_PRESENT).
I will include the changes in the next version.


OK.

Thanks,
Dave



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-17-2012, 05:29 PM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

On 02/17/2012 07:25 PM, Dave Anderson wrote:



----- Original Message -----

On 02/17/2012 12:43 AM, Dave Anderson wrote:



----- Original Message -----

On 02/16/2012 09:52 PM, Dave Anderson wrote:



----- Original Message -----
...

So just do the same thing -- no verbose expanation is required.


There are two ways to fix this :

1) Fix dump_mem_map*() to print the header only when there is
information to dump.

--- a/memory.c
+++ b/memory.c
@@ -4637,13 +4637,6 @@ dump_mem_map_SPARSEMEM(struct meminfo
*mi)
continue;
}

- if (print_hdr) {
- if (!(pc->curcmd_flags&
HEADER_PRINTED))
- fprintf(fp, "%s", hdr);
- print_hdr = FALSE;
- pc->curcmd_flags |= HEADER_PRINTED;
- }
-
pp = section_mem_map_addr(section);
pp = sparse_decode_mem_map(pp, section_nr);
phys = (physaddr_t) section_nr *
PAGES_PER_SECTION()
* PAGESIZE();
@@ -4854,6 +4847,13 @@ dump_mem_map_SPARSEMEM(struct meminfo
*mi)
}

if (bufferindex> buffersize) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags&
HEADER_PRINTED))
+ fprintf(fp,
"%s",
hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |=
HEADER_PRINTED;
+ }
+
fprintf(fp, "%s",
outputbuffer);
bufferindex = 0;
}
@@ -4867,6 +4867,13 @@ dump_mem_map_SPARSEMEM(struct meminfo
*mi)
}

if (bufferindex> 0) {
+ if (print_hdr) {
+ if (!(pc->curcmd_flags&
HEADER_PRINTED))
+ fprintf(fp, "%s", hdr);
+ print_hdr = FALSE;
+ pc->curcmd_flags |= HEADER_PRINTED;
+ }
+
fprintf(fp, "%s", outputbuffer);
}

Similarly for the dump_mem_map().

2) Fix ppc_pgd_vtop() to return FALSE if the paddr>
machdep->memsize

--- a/ppc.c
+++ b/ppc.c
@@ -438,6 +438,10 @@ ppc_pgd_vtop(ulong *pgd, ulong vaddr,
physaddr_t
*paddr, int verbose)

*paddr = PAGEBASE(pte) + PAGEOFFSET(vaddr);

+ if (*paddr> machdep->memsize)
+ /* We don't have pages above System RAM */
+ return FALSE;
+
return TRUE;

no_page:

I prefer the (1). What do you think ?


Hi Suzuki,

Hmmm -- with respect to (1), I suppose that would work, although
given that both x86 and x86_64 pass through
dump_mem_map_SPARSEMEM()
without printing the header in a non-existent-page case, I don't
understand why ppc is different?

Yep, I digged into that a little, but not deep enough to debug it
with
a dump. Nothing was evident from the code .


Right -- I tried debugging it from the x86 and x86_64 perspective,
and couldn't see why ppc would be different! ;-)

Ah, well, I was talking about the x86_64 dump.
I could explain the PPC side of affairs :-). We have page the
following
flags set for the page(with the actual PPC44x page flags support) :

VIRTUAL PHYSICAL
d1002000 20ec00000

PAGE DIRECTORY: c0578000
PGD: c0579a20 => c784b000
PMD: c784b000 => c784b010
PTE: c784b010 => 20ec0051b
PAGE: 20ec00000

PTE PHYSICAL FLAGS
20ec0051b 20ec00000 (PRESENT|RW|GUARDED|NO_CACHE|DIRTY|ACCESSED)


So the page is 'present', but there is no page descriptor associated
with it.
Hence dump_mem_map() would still be called and hence the problem.

Why doesn't it get called in x86_64 case even when the flags indicate
page 'PRESENT' ?


I don't know -- that's what I was asking!


The only suspect is :

if (page_exists) {

if ((pc->flags & DEVMEM) && (paddr >= VTOP(vt->high_memory))) <<

return;


But I'd like to prevent it

in all cases with the patch to do_vtop().

Yep, thats the best way to fix it as of now.

Thanks
Suzuki

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-18-2012, 05:20 PM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

On 02/18/2012 12:38 AM, Dave Anderson wrote:



----- Original Message -----

On 02/17/2012 07:25 PM, Dave Anderson wrote:

...

Why doesn't it get called in x86_64 case even when the flags indicate
page 'PRESENT' ?


I don't know -- that's what I was asking!


The only suspect is :

if (page_exists) {

if ((pc->flags& DEVMEM)&& (paddr>= VTOP(vt->high_memory)))<<

return;


I'm not sure whether you are testing ppc on a dumpfile or a live
system using /dev/mem, and I don't know what your paddr value and
vs your vt->high_memory are.



I am testing this on a dumpfile and
vt->high_memory = 0xc8000000 .

Anyways, let us fix this with your suggestion.

Thanks
Suzuki

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-20-2012, 10:04 AM
"Suzuki K. Poulose"
 
Default vmalloc translation support for PPC

The following series implements :

* An infrastructure for platform based vmalloc translation for PPC32
* vmalloc translation support for PPC44x

Changes since V3:

* Use platform specific 'page flags'
* Avoid calling dump_mem_map() by checking if there is a page associated
with the physical memory. (Suggested by: Dave)

Changes since V2:

* Rebased to crash-6.0.3
* Maintains a list of probe functions, rather than platform
definitions.


Each platform can define their own probe_function which would get the name of the
ppc platform (read from kernel) and the probe can check if it is one of its variant.
The probe function can then update the 'platform' defintions for the virtual address
translation.

If none of the defined platforms match, we fall back to using the default PPC32
definitions.


---

Suzuki K. Poulose (4):
Avoid dump_mem_map when there is no page
[ppc] virtual address translation bits for PPC44x
[ppc] Support for platform based Virtual address translation
[ppc] Non-linear address translation routine


defs.h | 101 +++++++++++++++++---
memory.c | 4 -
ppc.c | 318 ++++++++++++++++++++++++++++++++++++++------------------------
3 files changed, 280 insertions(+), 143 deletions(-)

--
Suzuki K. Poulose

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 03:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org