[PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Suzuki K. Poulose]

The series introduces an infrastructure to define platform specific
bits for page translation for PPC and PPC44x support for vmalloc
translation.

This is similar to what we have implemented for Crash-utility.

The patches are based makedumpfile-1.4.2 + PPC32 support patches
which is queued in for 1.4.3.

---

Suzuki K. Poulose (4):
      [makedumpfile][ppc] PPC44x page translation definitions
      [makedumpfile][ppc] Define platform descriptors for page translation
      [makedumpfile][ppc] Generic vmalloc translation support
      [makedumpfile] Add read_string routine


 arch/ppc.c     |  108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 makedumpfile.c |   14 +++++++
 makedumpfile.h |   21 +++++++++++
 3 files changed, 139 insertions(+), 4 deletions(-)

-- 
Suzuki Poulose


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v1 1/4] [makedumpfile] Add read_string routine

[Suzuki K. Poulose]

This patch adds a read_string() wrapper around readmem().

int read_string(int type_addr, unsigned long long addr, char *bufptr, size_t len);

The functionality is similar to that of readmem(), except that we stop reading
when we find an end-of-string marker than reading 'len' bytes.

This will be useful for reading the name of the 'powerpc' platform which is
needed for dynamic page address definition bits.


Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---

 makedumpfile.c |   12 ++++++++++++
 makedumpfile.h |    1 +
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index 901b85c..e978e1c 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -373,6 +373,18 @@ error:
 	return FALSE;
 }
 
+int
+read_string(int type_addr, unsigned long long addr, char *buf, size_t len)
+{
+	int i;
+
+	memset(buf, 0, len);
+	for (i = 0; i < len; i ++)
+		if (!readmem(VADDR, addr + i, &buf[i], 1))
+			break;
+	return i;
+}
+
 int32_t
 get_kernel_version(char *release)
 {
diff --git a/makedumpfile.h b/makedumpfile.h
index e43ea84..9dc254e 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -1243,6 +1243,7 @@ extern struct srcfile_table	srcfile_table;
 
 
 int readmem(int type_addr, unsigned long long addr, void *bufptr, size_t size);
+int read_string(int type_addr, unsigned long long addr, char *bufptr, size_t len);
 int get_str_osrelease_from_vmlinux(void);
 int read_vmcoreinfo_xen(void);
 int exclude_xen_user_domain(void);


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v1 2/4] [makedumpfile][ppc] Generic vmalloc translation support

[Suzuki K. Poulose]

This patch adds the generic vmalloc address translation support for PPC32.

There are different types of platforms under PPC32 and the vmalloc translation
requires the knowledge about the page translation bits for each of them. This patch
introduces a generic translation routine with some default values which may work
well for most of the platforms. Later patches in this series would add an
infrastructure to identify the platforms and dynamically change the translation
based on the platform definition.

Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---

 arch/ppc.c     |   40 ++++++++++++++++++++++++++++++++++++----
 makedumpfile.h |    6 ++++++
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/arch/ppc.c b/arch/ppc.c
index 2bc8d5f..2ca0dc5 100644
--- a/arch/ppc.c
+++ b/arch/ppc.c
@@ -77,7 +77,9 @@ vaddr_to_paddr_ppc(unsigned long vaddr)
 {
 	unsigned long *pgd, *pmd;
 	unsigned long long pte;
+	unsigned long pte_32;
 	unsigned long long paddr;
+	int res = 0;
 
 	paddr = vaddr_to_paddr_general(vaddr);
 	if (paddr != NOT_PADDR)
@@ -91,10 +93,40 @@ vaddr_to_paddr_ppc(unsigned long vaddr)
 	if (!is_vmalloc_addr_ppc(vaddr))
 		return (vaddr - info->kernel_start);
 
-	/*
-	 * TODO: Support vmalloc translation.
-	 */
-	ERRMSG("This makedumpfile does not support vmalloc translation.\n");
+	if ((SYMBOL(swapper_pg_dir) == NOT_FOUND_SYMBOL) &&
+		!readmem(VADDR, SYMBOL(swapper_pg_dir), &pgd, sizeof(pgd))) {
+		ERRMSG("Can't get the PGD for vmalloc translation. \n");
+		return NOT_PADDR;
+	}
+
+	pgd += vaddr >> PGDIR_SHIFT;
+	DEBUG_MSG("vaddr: 0x%lx , PGD = 0x%lx\n", vaddr, (unsigned long)pgd);
+	if (!readmem(VADDR, (unsigned long)pgd, &pmd, sizeof(pmd))) {
+		ERRMSG("Can't get the PMD for address 0x%lx\n.", vaddr);
+		return NOT_PADDR;
+	}
+
+	pmd += (PAGEBASE(vaddr) & (PTRS_PER_PTE - 1));
+	DEBUG_MSG("vaddr: 0x%lx , PMD = 0x%lx\n", vaddr, (unsigned long)pmd);
+
+	if (PTE_SIZE == sizeof(unsigned long long))
+		res = readmem(VADDR, (unsigned long)pmd, &pte, sizeof(pte));
+	else {
+		res = readmem(VADDR, (unsigned long)pmd, &pte_32, sizeof(pte_32));
+		pte = pte_32;
+	}
+
+	if (!res) {
+		ERRMSG("Can't get PTE for address 0x%lx\n", vaddr);
+		return NOT_PADDR;
+	}
+
+	DEBUG_MSG("vaddr: 0x%lx , PTE = 0x%llx\n", vaddr, (unsigned long long)pte);
+	if (pte & _PAGE_PRESENT) {
+		paddr = PAGEBASE(pte) | PAGEOFFSET(vaddr);
+		return paddr;
+	}
+
 	return NOT_PADDR;
 }
 
diff --git a/makedumpfile.h b/makedumpfile.h
index 9dc254e..f7603d7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -539,6 +539,12 @@ do { \
 #define _SECTION_SIZE_BITS	(24)
 #define _MAX_PHYSMEM_BITS	(44)
 
+#define PGDIR_SHIFT		(22)
+#define PTRS_PER_PTE		(1024)
+#define PTE_SIZE		(sizeof(unsigned long))
+
+#define _PAGE_PRESENT		(0x1)
+
 #endif
 
 #ifdef __s390x__


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v1 3/4] [makedumpfile][ppc] Define platform descriptors for page translation

[Suzuki K. Poulose]

This patch introduces the 'platform' descriptor and an infrastructure
to dynamically probe the platform where the core was generated.

struct platform {
        char *name;		/* name of the platform */
        int pgdir_shift;
        int ptrs_per_pte;
        int pte_size;		/* size of a pte (32/64) */
} base_platform;

The above structure would hold the definitions for page translation for the
platform where the core was generated.

We maintain a list of probe functions, defined for each platform, which can
check if the 'platform string' (obtained by reading the kernel variable
 'powerpc_base_platform') matches one of its variants and update the descriptor
with the specific values. There is a default probe function -at the end of the list - 
which would set the default values for the translation.

get_machdep_info_ppc() will call ppc_probe_base_platform() to scan through
the list of known platform probes to identify the running platform and update
the descriptor accordingly.

This infrastructure will be used for the vmalloc translation for PPC. Since there
are a variety of platforms out there with different translation schemes, this 
infrastructure would help us to support all of them with very little overhead.

Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---

 arch/ppc.c     |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.c |    2 ++
 makedumpfile.h |   16 +++++++++++++---
 3 files changed, 68 insertions(+), 3 deletions(-)

diff --git a/arch/ppc.c b/arch/ppc.c
index 2ca0dc5..0ad2cf4 100644
--- a/arch/ppc.c
+++ b/arch/ppc.c
@@ -25,6 +25,56 @@
 #include "../elf_info.h"
 #include "../makedumpfile.h"
 
+#define MAX_PLATFORM_LEN	64	/* length of platform string */
+
+struct platform {
+	char *name;
+	int pgdir_shift;
+	int ptrs_per_pte;
+	int pte_size;
+} base_platform;
+
+typedef int (*probe_func_t)(char *, struct platform *);
+
+static int probe_default_platform(char *, struct platform*);
+
+probe_func_t probe_platforms[] = {
+	probe_default_platform,		/* This should be at the end of the list */
+	NULL
+};
+
+static int probe_default_platform(char *s, struct platform *p)
+{
+	/* Accept as the default platform */
+	p->name = strdup(s);
+	p->pgdir_shift = DEFAULT_PGDIR_SHIFT;
+	p->ptrs_per_pte = DEFAULT_PTRS_PER_PTE;
+	p->pte_size = DEFAULT_PTE_SIZE;
+
+	return TRUE;
+}
+
+static void
+ppc_probe_base_platform(void)
+{
+	unsigned long ptr;
+	char ppc_platform[MAX_PLATFORM_LEN];
+	int i;
+
+
+	if (SYMBOL(powerpc_base_platform) == NOT_FOUND_SYMBOL ||
+	    !readmem(VADDR, SYMBOL(powerpc_base_platform), &ptr, sizeof(ptr)) ||
+	    !read_string(VADDR, ptr, ppc_platform, MAX_PLATFORM_LEN - 1))
+		/* lets fallback to default if we couldn't find the platform */
+		ppc_platform[0] = '\0';
+
+	for(i = 0; probe_platforms[i] != NULL; i++) {
+		probe_func_t probe = probe_platforms[i];
+		if(probe(ppc_platform, &base_platform))
+			break;
+	}
+}
+
 int
 get_machdep_info_ppc(void)
 {
@@ -63,6 +113,9 @@ get_machdep_info_ppc(void)
 	info->vmalloc_start = vmalloc_start;
 	DEBUG_MSG("vmalloc_start: %lx\n", vmalloc_start);
 
+	ppc_probe_base_platform();
+	DEBUG_MSG("Using '%s' platform VM definitions\n", base_platform.name);
+
 	return TRUE;
 }
 
diff --git a/makedumpfile.c b/makedumpfile.c
index e978e1c..2550edc 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -855,6 +855,8 @@ get_symbol_info(void)
 	if (SYMBOL(__per_cpu_offset) != NOT_FOUND_SYMBOL)
 		SYMBOL_ARRAY_LENGTH_INIT(__per_cpu_offset, "__per_cpu_offset");
 
+	SYMBOL_INIT(powerpc_base_platform, "powerpc_base_platform");
+
 	return TRUE;
 }
 
diff --git a/makedumpfile.h b/makedumpfile.h
index f7603d7..3a5152c 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -539,9 +539,13 @@ do { \
 #define _SECTION_SIZE_BITS	(24)
 #define _MAX_PHYSMEM_BITS	(44)
 
-#define PGDIR_SHIFT		(22)
-#define PTRS_PER_PTE		(1024)
-#define PTE_SIZE		(sizeof(unsigned long))
+#define DEFAULT_PGDIR_SHIFT	(22)
+#define DEFAULT_PTRS_PER_PTE	(1024)
+#define DEFAULT_PTE_SIZE	(sizeof(unsigned long))
+
+#define PGDIR_SHIFT		(base_platform.pgdir_shift)
+#define PTRS_PER_PTE		(base_platform.ptrs_per_pte)
+#define PTE_SIZE		(base_platform.pte_size)
 
 #define _PAGE_PRESENT		(0x1)
 
@@ -1018,6 +1022,12 @@ struct symbol_table {
 	unsigned long long	high_memory;
 
 	/*
+	 * PPC platform string pointer. Used for
+	 * vmalloc translation.
+	 */
+	unsigned long long	powerpc_base_platform;
+
+	/*
 	 * for sadump
 	 */
 	unsigned long long	linux_banner;


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v1 4/4] [makedumpfile][ppc] PPC44x page translation definitions

[Suzuki K. Poulose]

This patch defines the translation bits for PPC44x.


Signed-off-by : Suzuki K. Poulose <suzuki@in.ibm.com>
---

 arch/ppc.c     |   15 +++++++++++++++
 makedumpfile.h |    4 ++++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/ppc.c b/arch/ppc.c
index 0ad2cf4..b63a617 100644
--- a/arch/ppc.c
+++ b/arch/ppc.c
@@ -37,12 +37,27 @@ struct platform {
 typedef int (*probe_func_t)(char *, struct platform *);
 
 static int probe_default_platform(char *, struct platform*);
+static int probe_ppc44x_platform(char *, struct platform*);
 
 probe_func_t probe_platforms[] = {
+	probe_ppc44x_platform,
 	probe_default_platform,		/* This should be at the end of the list */
 	NULL
 };
 
+static int probe_ppc44x_platform(char *s, struct platform *p)
+{
+	if (!strncmp(s, "ppc440", 6) || strcmp(s, "ppc470")) {
+		p->name = strdup(s);
+		p->pgdir_shift = PPC44x_PGDIR_SHIFT;
+		p->ptrs_per_pte = PPC44x_PTRS_PER_PTE;
+		p->pte_size = PPC44x_PTE_SIZE;
+
+		return TRUE;
+	}
+	return FALSE;
+}
+	
 static int probe_default_platform(char *s, struct platform *p)
 {
 	/* Accept as the default platform */
diff --git a/makedumpfile.h b/makedumpfile.h
index 3a5152c..430202b 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -543,6 +543,10 @@ do { \
 #define DEFAULT_PTRS_PER_PTE	(1024)
 #define DEFAULT_PTE_SIZE	(sizeof(unsigned long))
 
+#define PPC44x_PGDIR_SHIFT	(21)
+#define PPC44x_PTRS_PER_PTE	(512)
+#define PPC44x_PTE_SIZE 	(sizeof(unsigned long long))
+
 #define PGDIR_SHIFT		(base_platform.pgdir_shift)
 #define PTRS_PER_PTE		(base_platform.ptrs_per_pte)
 #define PTE_SIZE		(base_platform.pte_size)


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Atsushi Kumagai]

Hi, Suzuki

On Thu, 16 Feb 2012 09:05:17 +0530
"Suzuki K. Poulose" <suzuki@in.ibm.com> wrote:

> The series introduces an infrastructure to define platform specific
> bits for page translation for PPC and PPC44x support for vmalloc
> translation.
> 
> This is similar to what we have implemented for Crash-utility.
> 
> The patches are based makedumpfile-1.4.2 + PPC32 support patches
> which is queued in for 1.4.3.
> 
> ---
> 
> Suzuki K. Poulose (4):
>       [makedumpfile][ppc] PPC44x page translation definitions
>       [makedumpfile][ppc] Define platform descriptors for page translation
>       [makedumpfile][ppc] Generic vmalloc translation support
>       [makedumpfile] Add read_string routine
> 
> 
>  arch/ppc.c     |  108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>  makedumpfile.c |   14 +++++++
>  makedumpfile.h |   21 +++++++++++
>  3 files changed, 139 insertions(+), 4 deletions(-)
> 
> -- 
> Suzuki Poulose

Could you tell me what kind of data is stored in vmalloc region in PPC ?
I want to estimate importance of your patches for makedumpfile.

Thanks
Atsushi Kumagai

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Suzuki K. Poulose]

On 02/17/2012 06:02 AM, Atsushi Kumagai wrote:
> Hi, Suzuki
>
> On Thu, 16 Feb 2012 09:05:17 +0530
> "Suzuki K. Poulose"<suzuki@in.ibm.com>  wrote:
>
>> The series introduces an infrastructure to define platform specific
>> bits for page translation for PPC and PPC44x support for vmalloc
>> translation.
>>
>> This is similar to what we have implemented for Crash-utility.
>>
>> The patches are based makedumpfile-1.4.2 + PPC32 support patches
>> which is queued in for 1.4.3.
>>
>> ---
>>
>> Suzuki K. Poulose (4):
>>        [makedumpfile][ppc] PPC44x page translation definitions
>>        [makedumpfile][ppc] Define platform descriptors for page translation
>>        [makedumpfile][ppc] Generic vmalloc translation support
>>        [makedumpfile] Add read_string routine
>>
>>
>>   arch/ppc.c     |  108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>   makedumpfile.c |   14 +++++++
>>   makedumpfile.h |   21 +++++++++++
>>   3 files changed, 139 insertions(+), 4 deletions(-)
>>
>> --
>> Suzuki Poulose
>
> Could you tell me what kind of data is stored in vmalloc region in PPC ?
> I want to estimate importance of your patches for makedumpfile.
I know at least the modules are loaded in the vmalloc'd region. I have
Cc'ed linux-ppc dev. We should be able to get enough info from the experts here.

Josh / Kumar / Others,

Could you please let us know your thoughts ?

Thanks

Suzuki

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Suzuki K. Poulose]

On 02/17/2012 06:02 AM, Atsushi Kumagai wrote:
> Hi, Suzuki
>
> On Thu, 16 Feb 2012 09:05:17 +0530
> "Suzuki K. Poulose"<suzuki@in.ibm.com>  wrote:
>
>> The series introduces an infrastructure to define platform specific
>> bits for page translation for PPC and PPC44x support for vmalloc
>> translation.
>>
>> This is similar to what we have implemented for Crash-utility.
>>
>> The patches are based makedumpfile-1.4.2 + PPC32 support patches
>> which is queued in for 1.4.3.
>>
>> ---
>>
>> Suzuki K. Poulose (4):
>>        [makedumpfile][ppc] PPC44x page translation definitions
>>        [makedumpfile][ppc] Define platform descriptors for page translation
>>        [makedumpfile][ppc] Generic vmalloc translation support
>>        [makedumpfile] Add read_string routine
>>
>>
>>   arch/ppc.c     |  108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>   makedumpfile.c |   14 +++++++
>>   makedumpfile.h |   21 +++++++++++
>>   3 files changed, 139 insertions(+), 4 deletions(-)
>>
>> --
>> Suzuki Poulose
>
> Could you tell me what kind of data is stored in vmalloc region in PPC ?
> I want to estimate importance of your patches for makedumpfile.
I know at least the modules are loaded in the vmalloc'd region. I have
Cc'ed linux-ppc dev. We should be able to get enough info from the experts here.

Josh / Kumar / Others,

Could you please let us know your thoughts ?

Thanks

Suzuki


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Benjamin Herrenschmidt]

On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > Could you tell me what kind of data is stored in vmalloc region in
> PPC ?
> > I want to estimate importance of your patches for makedumpfile.
> I know at least the modules are loaded in the vmalloc'd region. I have
> Cc'ed linux-ppc dev. We should be able to get enough info from the
> experts here.
> 
> Josh / Kumar / Others,
> 
> Could you please let us know your thoughts ?

Modules, driver IO mappings, etc... I can see that being useful for
crashdumps.

Cheers,
Ben.

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Benjamin Herrenschmidt]

On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > Could you tell me what kind of data is stored in vmalloc region in
> PPC ?
> > I want to estimate importance of your patches for makedumpfile.
> I know at least the modules are loaded in the vmalloc'd region. I have
> Cc'ed linux-ppc dev. We should be able to get enough info from the
> experts here.
> 
> Josh / Kumar / Others,
> 
> Could you please let us know your thoughts ?

Modules, driver IO mappings, etc... I can see that being useful for
crashdumps.

Cheers,
Ben.



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Atsushi Kumagai]

Hi, Benjamin
Hi, Suzuki

On Fri, 17 Feb 2012 19:39:29 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > > Could you tell me what kind of data is stored in vmalloc region in
> > PPC ?
> > > I want to estimate importance of your patches for makedumpfile.
> > I know at least the modules are loaded in the vmalloc'd region. I have
> > Cc'ed linux-ppc dev. We should be able to get enough info from the
> > experts here.
> > 
> > Josh / Kumar / Others,
> > 
> > Could you please let us know your thoughts ?
> 
> Modules, driver IO mappings, etc... I can see that being useful for
> crashdumps.

Thank you for your information.

The above data may be required for one function of makedumpfile (filter
out kernel data) but not so crucial for makedumpfile as page descriptors
and related data(e.g. pglist_data).

Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?


Thanks
Atsushi Kumagai

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Atsushi Kumagai]

Hi, Benjamin
Hi, Suzuki

On Fri, 17 Feb 2012 19:39:29 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > > Could you tell me what kind of data is stored in vmalloc region in
> > PPC ?
> > > I want to estimate importance of your patches for makedumpfile.
> > I know at least the modules are loaded in the vmalloc'd region. I have
> > Cc'ed linux-ppc dev. We should be able to get enough info from the
> > experts here.
> > 
> > Josh / Kumar / Others,
> > 
> > Could you please let us know your thoughts ?
> 
> Modules, driver IO mappings, etc... I can see that being useful for
> crashdumps.

Thank you for your information.

The above data may be required for one function of makedumpfile (filter
out kernel data) but not so crucial for makedumpfile as page descriptors
and related data(e.g. pglist_data).

Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?


Thanks
Atsushi Kumagai

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Suzuki K. Poulose]

On 02/20/2012 03:26 PM, Atsushi Kumagai wrote:
> Hi, Benjamin
> Hi, Suzuki
>
> On Fri, 17 Feb 2012 19:39:29 +1100
> Benjamin Herrenschmidt<benh@kernel.crashing.org>  wrote:
>
>> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
>>>> Could you tell me what kind of data is stored in vmalloc region in
>>> PPC ?
>>>> I want to estimate importance of your patches for makedumpfile.
>>> I know at least the modules are loaded in the vmalloc'd region. I have
>>> Cc'ed linux-ppc dev. We should be able to get enough info from the
>>> experts here.
>>>
>>> Josh / Kumar / Others,
>>>
>>> Could you please let us know your thoughts ?
>>
>> Modules, driver IO mappings, etc... I can see that being useful for
>> crashdumps.
>
> Thank you for your information.
>
> The above data may be required for one function of makedumpfile (filter
> out kernel data) but not so crucial for makedumpfile as page descriptors
> and related data(e.g. pglist_data).
>
> Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
> support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?

Yep,  fine with me.

Thanks
Suzuki

Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32

[Suzuki K. Poulose]

On 02/20/2012 03:26 PM, Atsushi Kumagai wrote:
> Hi, Benjamin
> Hi, Suzuki
>
> On Fri, 17 Feb 2012 19:39:29 +1100
> Benjamin Herrenschmidt<benh@kernel.crashing.org>  wrote:
>
>> On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
>>>> Could you tell me what kind of data is stored in vmalloc region in
>>> PPC ?
>>>> I want to estimate importance of your patches for makedumpfile.
>>> I know at least the modules are loaded in the vmalloc'd region. I have
>>> Cc'ed linux-ppc dev. We should be able to get enough info from the
>>> experts here.
>>>
>>> Josh / Kumar / Others,
>>>
>>> Could you please let us know your thoughts ?
>>
>> Modules, driver IO mappings, etc... I can see that being useful for
>> crashdumps.
>
> Thank you for your information.
>
> The above data may be required for one function of makedumpfile (filter
> out kernel data) but not so crucial for makedumpfile as page descriptors
> and related data(e.g. pglist_data).
>
> Moreover, I'm preparing the release of v1.4.3 now, so I'll merge vmalloc
> support for PPC32 into v1.4.4. Is it all right for you, Suzuki ?

Yep,  fine with me.

Thanks
Suzuki


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 1/4] [makedumpfile] Add read_string routine

[Atsushi Kumagai]

Hello Suzuki,

On Thu, 16 Feb 2012 09:05:40 +0530
"Suzuki K. Poulose" <suzuki@in.ibm.com> wrote:

> This patch adds a read_string() wrapper around readmem().
> 
> int read_string(int type_addr, unsigned long long addr, char *bufptr, size_t len);
> 
> The functionality is similar to that of readmem(), except that we stop reading
> when we find an end-of-string marker than reading 'len' bytes.
> 
> This will be useful for reading the name of the 'powerpc' platform which is
> needed for dynamic page address definition bits.
[...]
> +int
> +read_string(int type_addr, unsigned long long addr, char *buf, size_t len)
> +{
> +	int i;
> +
> +	memset(buf, 0, len);
> +	for (i = 0; i < len; i ++)
> +		if (!readmem(VADDR, addr + i, &buf[i], 1))
> +			break;
> +	return i;
> +}

Sorry for late reply. I reviewed your patches and I have question about
read_string().

You explained that read_string() stops reading when end-of-string appear,
but your code seems to read just 'len' bytes regardless of end-of-string. 
Maybe, do you expect readmem() to stop reading when end-of-string appear ?

Additionally, it is inefficient to call readmem() to read each byte of data.

Therefore, the code below may satisfy you ?

---------------------------------------------------------------------------
diff --git a/makedumpfile.c b/makedumpfile.c
index fea26af..5743d74 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -389,13 +389,29 @@ error:
 int
 read_string(int type_addr, unsigned long long addr, char *buf, size_t len)
 {
-       int i;
+       int i, remnant;
+       const int region = 512;

        memset(buf, 0, len);
-       for (i = 0; i < len; i ++)
-               if (!readmem(VADDR, addr + i, &buf[i], 1))
+       for (i = 0; i < len; i += region) {
+               /*
+                * buf[len] must be end-of-string.
+                */
+               remnant = len - i;
+               if (remnant == 1) {
                        break;
-       return i;
+               } else if (remnant <= region) {
+                       if (!readmem(type_addr, addr + i, &buf[i], remnant - 1 ))
+                               return ERROR;
+                       break;
+               }
+
+               if (!readmem(type_addr, addr + i, &buf[i], region))
+                       return ERROR;
+               if (strlen(buf) != i + region)
+                       break;
+       }
+       return strlen(buf);
 }


Thanks
Atsushi Kumagai

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec