Skip to contentSkip to conversation

Allow Xen Dom0 page filtering

PATCH In review Petr Tesarik 2 participants 15 messages Mar 27, 2014 – Apr 3, 2014

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover Allow Xen Dom0 page filtering

Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there are in fact only a few missing pieces. With the following two patches, I was able to produce a dump even with high dump levels (-d17 and -d31).

Needless to say, this can reduce the size of Dom0 dumps considerably.

Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

 makedumpfile.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#1 lore raw

cover Allow Xen Dom0 page filtering

I'm resending this, now with correct mail threading. Sorry for the noise.

Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there are in fact only a few missing pieces. With the following two patches, I was able to produce a dump even with high dump levels (-d17 and -d31).

Needless to say, this can reduce the size of Dom0 dumps considerably.

Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

 makedumpfile.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#2 lore raw

PATCH 1/2 Earlier initialization of dom0_mapnr

Xen dumps fail, because the p2m mapping is initialized too late. The dependency goes like this:

- Xen uses FLATMEM
- get_mm_flatmem() uses info->dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in get_machdep_info()

---
 makedumpfile.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
makedumpfile.c +6 -6
index e91583d..d3f5237 100644
@@ -3128,6 +3128,12 @@ out:
 	if (!get_max_mapnr())
 		return FALSE;
 
+	if (debug_info && !get_machdep_info())
+		return FALSE;
+
+	if (is_xen_memory() && !get_dom0_mapnr())
+		return FALSE;
+
 	if (info->flag_cyclic) {
 		if (info->bufsize_cyclic == 0) {
 			if (!calculate_cyclic_buffer_size())
@@ -3185,9 +3191,6 @@ out:
 		if (info->flag_sadump)
 			(void) sadump_virt_phys_base();
 
-		if (!get_machdep_info())
-			return FALSE;
-
 		if (info->flag_sadump) {
 			int online_cpus;
 
@@ -3233,9 +3236,6 @@ out:
 			return FALSE;
 	}
 
-	if (is_xen_memory() && !get_dom0_mapnr())
-		return FALSE;
-
 	if (!get_value_for_old_linux())
 		return FALSE;
 
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#3 lore raw

RE: [PATCH 1/2] Earlier initialization of dom0_mapnr

Hello Petr,

Quoted 18 lines

Xen dumps fail, because the p2m mapping is initialized too late. The dependency goes like this:

- Xen uses FLATMEM
- get_mm_flatmem() uses info->dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in get_machdep_info()

---
makedumpfile.c | 12 ++++++------

1 file changed, 6 insertions(+), 6 deletions(-)
makedumpfile.c +0 -0
index e91583d..d3f5237 100644

makedumpfile.c out: · line 3132

Quoted 5 lines
makedumpfile.c +2 -0
@@ -3128,6 +3128,12 @@ out:
 	if (!get_max_mapnr())
 		return FALSE;
 
+	if (debug_info && !get_machdep_info())
+		return FALSE;

You have to move get_machdep_info() after cache_init() since get_machdep_info() calls readmem() on some architectures. Otherwise, readmem() calls cache_alloc() without the cache initialization.

Thanks
Atsushi Kumagai

Quoted 28 lines
makedumpfile.c +4 -7
+
+	if (is_xen_memory() && !get_dom0_mapnr())
+		return FALSE;
+
 	if (info->flag_cyclic) {
 		if (info->bufsize_cyclic == 0) {
 			if (!calculate_cyclic_buffer_size())
@@ -3185,9 +3191,6 @@ out:
 		if (info->flag_sadump)
 			(void) sadump_virt_phys_base();
 
-		if (!get_machdep_info())
-			return FALSE;
-
 		if (info->flag_sadump) {
 			int online_cpus;
 
@@ -3233,9 +3236,6 @@ out:
 			return FALSE;
 	}
 
-	if (is_xen_memory() && !get_dom0_mapnr())
-		return FALSE;
-
 	if (!get_value_for_old_linux())
 		return FALSE;
 
--
Quoted 1 line

1.8.4.5

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#4 lore raw

Re: [PATCH 1/2] Earlier initialization of dom0_mapnr

Quoted 23 lines · On Fri, 28 Mar 2014 08:18:13 +0000 Atsushi Kumagai…

Hello Petr,

Quoted 21 lines

Xen dumps fail, because the p2m mapping is initialized too late. The dependency goes like this:

- Xen uses FLATMEM
- get_mm_flatmem() uses info->dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in get_machdep_info()

---
makedumpfile.c | 12 ++++++------

1 file changed, 6 insertions(+), 6 deletions(-)
makedumpfile.c +0 -0
index e91583d..d3f5237 100644
@@ -3128,6 +3128,12 @@ out:
 	if (!get_max_mapnr())
 		return FALSE;
 
Quoted 7 lines

makedumpfile.c out: · line 3132

Quoted 2 lines
makedumpfile.c +2 -0
+	if (debug_info && !get_machdep_info())
+		return FALSE;

You have to move get_machdep_info() after cache_init() since get_machdep_info() calls readmem() on some architectures. Otherwise, readmem() calls cache_alloc() without the cache initialization.

*sigh*

I suspected that the dependencies may be more complex... Out of curiosity, do you already have an overview (dependency graph or similar)? And if not, would you appreciate it if I created one?

Petr T

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#5 lore raw

RE: [PATCH 1/2] Earlier initialization of dom0_mapnr

Quoted 34 lines
Quoted 23 lines · On Fri, 28 Mar 2014 08:18:13 +0000 Atsushi Kumagai…

Hello Petr,

Quoted 21 lines

Xen dumps fail, because the p2m mapping is initialized too late. The dependency goes like this:

- Xen uses FLATMEM
- get_mm_flatmem() uses info->dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in get_machdep_info()

---
makedumpfile.c | 12 ++++++------

1 file changed, 6 insertions(+), 6 deletions(-)
makedumpfile.c +0 -0
index e91583d..d3f5237 100644
@@ -3128,6 +3128,12 @@ out:
 	if (!get_max_mapnr())
 		return FALSE;
 
Quoted 7 lines

makedumpfile.c out: · line 3132

Quoted 2 lines
makedumpfile.c +2 -0
+	if (debug_info && !get_machdep_info())
+		return FALSE;

You have to move get_machdep_info() after cache_init() since get_machdep_info() calls readmem() on some architectures. Otherwise, readmem() calls cache_alloc() without the cache initialization.

Quoted 5 lines

*sigh*

I suspected that the dependencies may be more complex... Out of curiosity, do you already have an overview (dependency graph or similar)? And if not, would you appreciate it if I created one?

I'm afraid that I don't have such a stuff, but it will be very helpful for maintenance and clean-up since initial() was getting complex by additional features. So I will appreciate your work.

Thanks
Atsushi Kumagai

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#6 lore raw

v2 cover Allow Xen Dom0 page filtering

In reply to Atsushi Kumagai

Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there are in fact only a few missing pieces. With the following two patches, I was able to produce a dump even with high dump levels (-d17 and -d31).

Needless to say, this can reduce the size of Dom0 dumps considerably.

Changes in v2:

* Call get_machdep_info() after cache_init(), so it can use readmem(VADDR, ...)

This now works for me after reverting commit ebe2fa3a.

Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

 makedumpfile.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#7 lore raw

PATCH v2 1/2 Earlier initialization of dom0_mapnr

From: Petr Tesarik <[email protected]>

Xen dumps fail, because the p2m mapping is initialized too late. The dependency goes like this:

- Xen uses FLATMEM
- get_mm_flatmem() uses info->dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in get_machdep_info()

---
 makedumpfile.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
makedumpfile.c +6 -6
index e91583d..1117598 100644
@@ -3181,13 +3181,16 @@ out:
 	if (!is_xen_memory() && !cache_init())
 		return FALSE;
 
+	if (debug_info && !get_machdep_info())
+		return FALSE;
+
+	if (is_xen_memory() && !get_dom0_mapnr())
+		return FALSE;
+
 	if (debug_info) {
 		if (info->flag_sadump)
 			(void) sadump_virt_phys_base();
 
-		if (!get_machdep_info())
-			return FALSE;
-
 		if (info->flag_sadump) {
 			int online_cpus;
 
@@ -3233,9 +3236,6 @@ out:
 			return FALSE;
 	}
 
-	if (is_xen_memory() && !get_dom0_mapnr())
-		return FALSE;
-
 	if (!get_value_for_old_linux())
 		return FALSE;
 
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#8 lore raw

PATCH v2 2/2 Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

In reply to Petr Tesarik

From: Petr Tesarik <[email protected]>

If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the maximum PFN can be determined from the size of the mapping between PFN and MFN.

Using this approach, filtering works for Xen kernels without debuginfo (and even without adding more lines to VMCOREINFO).

---
 makedumpfile.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)
makedumpfile.c +22 -1
index 1117598..341fbe8 100644
@@ -189,9 +189,30 @@ get_dom0_mapnr()
 		}
 
 		info->dom0_mapnr = max_pfn;
-		DEBUG_MSG("domain-0 pfn : %llx\n", info->dom0_mapnr);
+	} else if (info->p2m_frames) {
+		unsigned long mfns[MFNS_PER_FRAME];
+		unsigned long mfn_idx = info->p2m_frames - 1;
+		unsigned long long maddr;
+		unsigned i;
+
+		maddr = pfn_to_paddr(info->p2m_mfn_frame_list[mfn_idx]);
+		if (!readmem(MADDR_XEN, maddr, &mfns, sizeof(mfns))) {
+			ERRMSG("Can't read %ld domain-0 mfns at 0x%llu\n",
+				(long)MFNS_PER_FRAME, maddr);
+			return FALSE;
+		}
+
+		for (i = 0; i < MFNS_PER_FRAME; ++i)
+			if (!mfns[i])
+				break;
+
+		info->dom0_mapnr = mfn_idx * MFNS_PER_FRAME + i;
+	} else {
+		/* dom0_mapnr is unavailable, which may be non-critical */
+		return TRUE;
 	}
 
+	DEBUG_MSG("domain-0 pfn : %llx\n", info->dom0_mapnr);
 	return TRUE;
 }
 
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#9 lore raw

cover Allow Xen Dom0 page filtering

In reply to Petr Tesarik

Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there are in fact only a few missing pieces. With the following two patches, I was able to produce a dump even with high dump levels (-d17 and -d31).

Needless to say, this can reduce the size of Dom0 dumps considerably.

Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

 makedumpfile.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#10 lore raw
In reply to Petr Tesarik

Hello Petr,

This looks good to me, I'll merge it into v1.5.6.

Thanks
Atsushi Kumagai

Quoted 16 lines

Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there are in fact only a few missing pieces. With the following two patches, I was able to produce a dump even with high dump levels (-d17 and -d31).

Needless to say, this can reduce the size of Dom0 dumps considerably.

Changes in v2:

* Call get_machdep_info() after cache_init(), so it can use readmem(VADDR, ...)

This now works for me after reverting commit ebe2fa3a.

Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

Quoted 5 lines

makedumpfile.c | 35 ++++++++++++++++++++++++++++-------

1 file changed, 28 insertions(+), 7 deletions(-)

--
1.8.4.5

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#11 lore raw

v2 cover Allow Xen Dom0 page filtering

In reply to Atsushi Kumagai

Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there are in fact only a few missing pieces. With the following two patches, I was able to produce a dump even with high dump levels (-d17 and -d31).

Needless to say, this can reduce the size of Dom0 dumps considerably.

Changes in v2:

* Call get_machdep_info() after cache_init(), so it can use readmem(VADDR, ...)

This now works for me after reverting commit ebe2fa3a.

Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

 makedumpfile.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#12 lore raw

PATCH v2 1/2 Earlier initialization of dom0_mapnr

From: Petr Tesarik <[email protected]>

Xen dumps fail, because the p2m mapping is initialized too late. The dependency goes like this:

- Xen uses FLATMEM
- get_mm_flatmem() uses info->dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in get_machdep_info()

---
 makedumpfile.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
makedumpfile.c +6 -6
index e91583d..1117598 100644
@@ -3181,13 +3181,16 @@ out:
 	if (!is_xen_memory() && !cache_init())
 		return FALSE;
 
+	if (debug_info && !get_machdep_info())
+		return FALSE;
+
+	if (is_xen_memory() && !get_dom0_mapnr())
+		return FALSE;
+
 	if (debug_info) {
 		if (info->flag_sadump)
 			(void) sadump_virt_phys_base();
 
-		if (!get_machdep_info())
-			return FALSE;
-
 		if (info->flag_sadump) {
 			int online_cpus;
 
@@ -3233,9 +3236,6 @@ out:
 			return FALSE;
 	}
 
-	if (is_xen_memory() && !get_dom0_mapnr())
-		return FALSE;
-
 	if (!get_value_for_old_linux())
 		return FALSE;
 
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#13 lore raw

PATCH v2 2/2 Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

In reply to Petr Tesarik

From: Petr Tesarik <[email protected]>

If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the maximum PFN can be determined from the size of the mapping between PFN and MFN.

Using this approach, filtering works for Xen kernels without debuginfo (and even without adding more lines to VMCOREINFO).

---
 makedumpfile.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)
makedumpfile.c +22 -1
index 1117598..341fbe8 100644
@@ -189,9 +189,30 @@ get_dom0_mapnr()
 		}
 
 		info->dom0_mapnr = max_pfn;
-		DEBUG_MSG("domain-0 pfn : %llx\n", info->dom0_mapnr);
+	} else if (info->p2m_frames) {
+		unsigned long mfns[MFNS_PER_FRAME];
+		unsigned long mfn_idx = info->p2m_frames - 1;
+		unsigned long long maddr;
+		unsigned i;
+
+		maddr = pfn_to_paddr(info->p2m_mfn_frame_list[mfn_idx]);
+		if (!readmem(MADDR_XEN, maddr, &mfns, sizeof(mfns))) {
+			ERRMSG("Can't read %ld domain-0 mfns at 0x%llu\n",
+				(long)MFNS_PER_FRAME, maddr);
+			return FALSE;
+		}
+
+		for (i = 0; i < MFNS_PER_FRAME; ++i)
+			if (!mfns[i])
+				break;
+
+		info->dom0_mapnr = mfn_idx * MFNS_PER_FRAME + i;
+	} else {
+		/* dom0_mapnr is unavailable, which may be non-critical */
+		return TRUE;
 	}
 
+	DEBUG_MSG("domain-0 pfn : %llx\n", info->dom0_mapnr);
 	return TRUE;
 }
 
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#14 lore raw

PATCH 2/2 Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable

In reply to Petr Tesarik

If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the maximum PFN can be determined from the size of the mapping between PFN and MFN.

Using this approach, filtering works for Xen kernels without debuginfo (and even without adding more lines to VMCOREINFO).

---
 makedumpfile.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)
makedumpfile.c +22 -1
index d3f5237..92e8a6a 100644
@@ -189,9 +189,30 @@ get_dom0_mapnr()
 		}
 
 		info->dom0_mapnr = max_pfn;
-		DEBUG_MSG("domain-0 pfn : %llx\n", info->dom0_mapnr);
+	} else if (info->p2m_frames) {
+		unsigned long mfns[MFNS_PER_FRAME];
+		unsigned long mfn_idx = info->p2m_frames - 1;
+		unsigned long long maddr;
+		unsigned i;
+
+		maddr = pfn_to_paddr(info->p2m_mfn_frame_list[mfn_idx]);
+		if (!readmem(MADDR_XEN, maddr, &mfns, sizeof(mfns))) {
+			ERRMSG("Can't read %ld domain-0 mfns at 0x%llu\n",
+				(long)MFNS_PER_FRAME, maddr);
+			return FALSE;
+		}
+
+		for (i = 0; i < MFNS_PER_FRAME; ++i)
+			if (!mfns[i])
+				break;
+
+		info->dom0_mapnr = mfn_idx * MFNS_PER_FRAME + i;
+	} else {
+		/* dom0_mapnr is unavailable, which may be non-critical */
+		return TRUE;
 	}
 
+	DEBUG_MSG("domain-0 pfn : %llx\n", info->dom0_mapnr);
 	return TRUE;
 }
 
Signature · 7 lines
1.8.4.5


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec