Hi, It looks that Xen support for crash have not been maintained since 2009. I am trying to fix this. Here it is small bundle of fixes: - xen: Always calculate max_cpus value, - xen: Read only crash notes for onlined CPUs, - x86/xen: Read variables from dynamically allocated per_cpu data, - xen: Get idle data from alternative source, - xen: Read data correctly from dynamically allocated console ring too. Daniel
max_cpus is not available since 20374 changeset (Miscellaneous data placement adjustments). It was moved to __initdata section. This section is freed after Xen initialization. Assume that max_cpus is always equal to XEN_HYPER_SIZE(cpumask_t) * 8. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> diff -Npru crash-6.0.8.orig/xen_hyper.c crash-6.0.8/xen_hyper.c --- crash-6.0.8.orig/xen_hyper.c 2012-06-29 16:59:18.000000000 +0200 +++ crash-6.0.8/xen_hyper.c 2012-07-05 14:52:59.000000000 +0200 @@ -1879,11 +1879,9 @@ xen_hyper_get_cpu_info(void) uint *cpu_idx; int i, j, cpus; - get_symbol_data("max_cpus", sizeof(xht->max_cpus), &xht->max_cpus); XEN_HYPER_STRUCT_SIZE_INIT(cpumask_t, "cpumask_t"); - if (XEN_HYPER_SIZE(cpumask_t) * 8 > xht->max_cpus) { - xht->max_cpus = XEN_HYPER_SIZE(cpumask_t) * 8; - } + xht->max_cpus = XEN_HYPER_SIZE(cpumask_t) * 8; + if (xht->cpumask) { free(xht->cpumask); }
Daniel Kiper
2012-Jul-05 15:01 UTC
[PATCH 2/5] xen: Read only crash notes for onlined CPUs
Read only crash notes for onlined CPUs. Crash notes for not running CPUs does not exist in core file. Do not try to read them. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> diff -Npru crash-6.0.8.orig/xen_hyper.c crash-6.0.8/xen_hyper.c --- crash-6.0.8.orig/xen_hyper.c 2012-07-05 15:34:45.000000000 +0200 +++ crash-6.0.8/xen_hyper.c 2012-07-05 15:35:05.000000000 +0200 @@ -633,18 +633,18 @@ xen_hyper_dumpinfo_init(void) } /* allocate a context area */ - size = sizeof(struct xen_hyper_dumpinfo_context) * XEN_HYPER_MAX_CPUS(); + size = sizeof(struct xen_hyper_dumpinfo_context) * machdep->get_smp_cpus(); if((xhdit->context_array = malloc(size)) == NULL) { error(FATAL, "cannot malloc dumpinfo table context space.\n"); } BZERO(xhdit->context_array, size); - size = sizeof(struct xen_hyper_dumpinfo_context_xen_core) * XEN_HYPER_MAX_CPUS(); + size = sizeof(struct xen_hyper_dumpinfo_context_xen_core) * machdep->get_smp_cpus(); if((xhdit->context_xen_core_array = malloc(size)) == NULL) { error(FATAL, "cannot malloc dumpinfo table context_xen_core_array space.\n"); } BZERO(xhdit->context_xen_core_array, size); addr = symbol_value("per_cpu__crash_notes"); - for (i = 0; i < XEN_HYPER_MAX_CPUS(); i++) { + for (i = 0; i < machdep->get_smp_cpus(); i++) { ulong addr_notes; addr_notes = xen_hyper_per_cpu(addr, i);
Daniel Kiper
2012-Jul-05 15:02 UTC
[PATCH 3/5] x86/xen: Read variables from dynamically allocated per_cpu data
per_cpu data is dynamically allocated since 21416 changeset (x86: Dynamically allocate percpu data area when a CPU comes online). Take into account that and read variables from correct address. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> diff -Npru crash-6.0.8.orig/xen_hyper.c crash-6.0.8/xen_hyper.c --- crash-6.0.8.orig/xen_hyper.c 2012-07-05 15:47:09.000000000 +0200 +++ crash-6.0.8/xen_hyper.c 2012-07-05 15:50:19.000000000 +0200 @@ -64,7 +64,6 @@ xen_hyper_init(void) machdep->get_smp_cpus(); machdep->memory_size(); -#ifdef IA64 if (symbol_exists("__per_cpu_offset")) { xht->flags |= XEN_HYPER_SMP; if((xht->__per_cpu_offset = malloc(sizeof(ulong) * XEN_HYPER_MAX_CPUS())) == NULL) { @@ -76,7 +75,6 @@ xen_hyper_init(void) error(FATAL, "cannot read __per_cpu_offset.\n"); } } -#endif #if defined(X86) || defined(X86_64) if (symbol_exists("__per_cpu_shift")) { diff -Npru crash-6.0.8.orig/xen_hyper_defs.h crash-6.0.8/xen_hyper_defs.h --- crash-6.0.8.orig/xen_hyper_defs.h 2012-06-29 16:59:18.000000000 +0200 +++ crash-6.0.8/xen_hyper_defs.h 2012-07-05 15:50:19.000000000 +0200 @@ -136,7 +136,13 @@ typedef uint32_t Elf_Word; #if defined(X86) || defined(X86_64) #define xen_hyper_per_cpu(var, cpu) \ - ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift)) + ({ ulong __var_addr; \ + if (xht->__per_cpu_offset) \ + __var_addr = (xht->flags & XEN_HYPER_SMP) ? \ + ((ulong)(var) + xht->__per_cpu_offset[cpu]) : (ulong)(var); \ + else \ + __var_addr = (ulong)(var) + ((ulong)(cpu) << xht->percpu_shift); \ + __var_addr; }) #elif defined(IA64) #define xen_hyper_per_cpu(var, cpu) \ ((xht->flags & XEN_HYPER_SMP) ? \
idle member was removed from struct schedule_data by 21422 changeset (Fix CPU hotplug after percpu data handling changes). Get idle data from alternative source. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> diff -Npru crash-6.0.8.orig/xen_hyper.c crash-6.0.8/xen_hyper.c --- crash-6.0.8.orig/xen_hyper.c 2012-07-05 16:05:31.000000000 +0200 +++ crash-6.0.8/xen_hyper.c 2012-07-05 16:08:52.000000000 +0200 @@ -397,7 +397,8 @@ xen_hyper_misc_init(void) XEN_HYPER_STRUCT_SIZE_INIT(schedule_data, "schedule_data"); XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_schedule_lock, "schedule_data", "schedule_lock"); XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_curr, "schedule_data", "curr"); - XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_idle, "schedule_data", "idle"); + if (MEMBER_EXISTS("schedule_data", "idle")) + XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_idle, "schedule_data", "idle"); XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_sched_priv, "schedule_data", "sched_priv"); XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_s_timer, "schedule_data", "s_timer"); XEN_HYPER_MEMBER_OFFSET_INIT(schedule_data_tick, "schedule_data", "tick"); @@ -539,7 +540,10 @@ xen_hyper_schedule_init(void) } schc->cpu_id = cpuid; schc->curr = ULONG(buf + XEN_HYPER_OFFSET(schedule_data_curr)); - schc->idle = ULONG(buf + XEN_HYPER_OFFSET(schedule_data_idle)); + if (MEMBER_EXISTS("schedule_data", "idle")) + schc->idle = ULONG(buf + XEN_HYPER_OFFSET(schedule_data_idle)); + else + schc->idle = xht->idle_vcpu_array[cpuid]; schc->sched_priv ULONG(buf + XEN_HYPER_OFFSET(schedule_data_sched_priv)); if (XEN_HYPER_VALID_MEMBER(schedule_data_tick))
Daniel Kiper
2012-Jul-05 15:04 UTC
[PATCH 5/5] xen: Read data correctly from dynamically allocated console ring too
console ring is dynamically allocated since 19543 changeset (New option conring_size= to allow larger console ring). Take into account that and read data correctly from it too. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> diff -Npru crash-6.0.8.orig/xen_hyper_command.c crash-6.0.8/xen_hyper_command.c --- crash-6.0.8.orig/xen_hyper_command.c 2012-06-29 16:59:18.000000000 +0200 +++ crash-6.0.8/xen_hyper_command.c 2012-07-05 16:22:35.000000000 +0200 @@ -590,24 +590,31 @@ xen_hyper_dump_log(void) ulong conring; char *buf; char last; + uint32_t conring_size; - conring = symbol_value("conring"); + get_symbol_data("conring", sizeof(ulong), &conring); get_symbol_data("conringc", sizeof(uint), &conringc); get_symbol_data("conringp", sizeof(uint), &conringp); + + if (symbol_exists("conring_size")) + get_symbol_data("conring_size", sizeof(uint32_t), &conring_size); + else + conring_size = XEN_HYPER_CONRING_SIZE; + warp = FALSE; - if (conringp >= XEN_HYPER_CONRING_SIZE) { - if ((start = conringp & (XEN_HYPER_CONRING_SIZE - 1))) { + if (conringp >= conring_size) { + if ((start = conringp & (conring_size - 1))) { warp = TRUE; } } else { start = 0; } - buf = GETBUF(XEN_HYPER_CONRING_SIZE); - readmem(conring, KVADDR, buf, XEN_HYPER_CONRING_SIZE, + buf = GETBUF(conring_size); + readmem(conring, KVADDR, buf, conring_size, "conring contents", FAULT_ON_ERROR); idx = start; - len = XEN_HYPER_CONRING_SIZE; + len = conring_size; last = 0; wrap_around:
----- Original Message -----> Hi, > > It looks that Xen support for crash have not been maintained > since 2009. I am trying to fix this. Here it is small > bundle of fixes: > - xen: Always calculate max_cpus value, > - xen: Read only crash notes for onlined CPUs, > - x86/xen: Read variables from dynamically allocated per_cpu data, > - xen: Get idle data from alternative source, > - xen: Read data correctly from dynamically allocated console ring > too. > > DanielDaniel, Can you absolutely confirm that these changes are all backwards-compatible? Thanks, Dave
On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote:> > > ----- Original Message ----- > > Hi, > > > > It looks that Xen support for crash have not been maintained > > since 2009. I am trying to fix this. Here it is small > > bundle of fixes: > > - xen: Always calculate max_cpus value, > > - xen: Read only crash notes for onlined CPUs, > > - x86/xen: Read variables from dynamically allocated per_cpu data, > > - xen: Get idle data from alternative source, > > - xen: Read data correctly from dynamically allocated console ring > > too. > > > > Daniel > > Daniel, > > Can you absolutely confirm that these changes are all backwards-compatible?I have not done tests with older versions of Xen. However, I made all patches with backward compatibility in mind. Anyway, If you wish I could do tests with let''s say Xen Ver. 3.4 and Xen Linux Kernel Ver. 2.6.18 at least. Daniel
Konrad Rzeszutek Wilk
2012-Jul-05 15:33 UTC
Re: [PATCH 0/5] crash: Small bundle of fixes for Xen
On Thu, Jul 05, 2012 at 05:29:50PM +0200, Daniel Kiper wrote:> On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: > > > > > > ----- Original Message ----- > > > Hi, > > > > > > It looks that Xen support for crash have not been maintained > > > since 2009. I am trying to fix this. Here it is small > > > bundle of fixes: > > > - xen: Always calculate max_cpus value, > > > - xen: Read only crash notes for onlined CPUs, > > > - x86/xen: Read variables from dynamically allocated per_cpu data, > > > - xen: Get idle data from alternative source, > > > - xen: Read data correctly from dynamically allocated console ring > > > too. > > > > > > Daniel > > > > Daniel, > > > > Can you absolutely confirm that these changes are all backwards-compatible? > > I have not done tests with older versions of Xen. However, > I made all patches with backward compatibility in mind. Anyway, > If you wish I could do tests with let''s say Xen Ver. 3.4 > and Xen Linux Kernel Ver. 2.6.18 at least.I think Dave is worried about it breaking with the version that is bundled with RHEL5U8?
----- Original Message -----> On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: > > > > > > ----- Original Message ----- > > > Hi, > > > > > > It looks that Xen support for crash have not been maintained > > > since 2009. I am trying to fix this. Here it is small > > > bundle of fixes: > > > - xen: Always calculate max_cpus value, > > > - xen: Read only crash notes for onlined CPUs, > > > - x86/xen: Read variables from dynamically allocated per_cpu > > > data, > > > - xen: Get idle data from alternative source, > > > - xen: Read data correctly from dynamically allocated console > > > ring > > > too. > > > > > > Daniel > > > > Daniel, > > > > Can you absolutely confirm that these changes are all > > backwards-compatible? > > I have not done tests with older versions of Xen. However, > I made all patches with backward compatibility in mind. Anyway, > If you wish I could do tests with let''s say Xen Ver. 3.4 > and Xen Linux Kernel Ver. 2.6.18 at least. > > DanielThat would be helpful -- I have very few Xen hypervisor sample dumpfiles, and if I''m not mistaken, RHEL5 only went as far as Xen 3.1-something? Dave>
On Thu, Jul 05, 2012 at 11:39:52AM -0400, Dave Anderson wrote:> > > ----- Original Message ----- > > On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: > > > > > > > > > ----- Original Message ----- > > > > Hi, > > > > > > > > It looks that Xen support for crash have not been maintained > > > > since 2009. I am trying to fix this. Here it is small > > > > bundle of fixes: > > > > - xen: Always calculate max_cpus value, > > > > - xen: Read only crash notes for onlined CPUs, > > > > - x86/xen: Read variables from dynamically allocated per_cpu > > > > data, > > > > - xen: Get idle data from alternative source, > > > > - xen: Read data correctly from dynamically allocated console > > > > ring > > > > too. > > > > > > > > Daniel > > > > > > Daniel, > > > > > > Can you absolutely confirm that these changes are all > > > backwards-compatible? > > > > I have not done tests with older versions of Xen. However, > > I made all patches with backward compatibility in mind. Anyway, > > If you wish I could do tests with let''s say Xen Ver. 3.4 > > and Xen Linux Kernel Ver. 2.6.18 at least. > > > > Daniel > > That would be helpful -- I have very few Xen hypervisor sample dumpfiles, > and if I''m not mistaken, RHEL5 only went as far as Xen 3.1-something?No problem. I will email you back. Daniel
>>> On 05.07.12 at 17:00, Daniel Kiper <daniel.kiper@oracle.com> wrote: > max_cpus is not available since 20374 changeset (Miscellaneous data > placement adjustments). It was moved to __initdata section. This section > is freed after Xen initialization. Assume that max_cpus is always > equal to XEN_HYPER_SIZE(cpumask_t) * 8.Using nr_cpu_ids, when available, would seem a better fit. And I donm''t see why, on dumps from old hypervisors, you wouldn''t want to continue using max_cpus. Oh, wait, I see - you would have to be able to tell whether it actually sits in .init.data, which might not be strait forward. Jan> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> > > diff -Npru crash-6.0.8.orig/xen_hyper.c crash-6.0.8/xen_hyper.c > --- crash-6.0.8.orig/xen_hyper.c 2012-06-29 16:59:18.000000000 +0200 > +++ crash-6.0.8/xen_hyper.c 2012-07-05 14:52:59.000000000 +0200 > @@ -1879,11 +1879,9 @@ xen_hyper_get_cpu_info(void) > uint *cpu_idx; > int i, j, cpus; > > - get_symbol_data("max_cpus", sizeof(xht->max_cpus), &xht->max_cpus); > XEN_HYPER_STRUCT_SIZE_INIT(cpumask_t, "cpumask_t"); > - if (XEN_HYPER_SIZE(cpumask_t) * 8 > xht->max_cpus) { > - xht->max_cpus = XEN_HYPER_SIZE(cpumask_t) * 8; > - } > + xht->max_cpus = XEN_HYPER_SIZE(cpumask_t) * 8; > + > if (xht->cpumask) { > free(xht->cpumask); > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
----- Original Message -----> On Thu, Jul 05, 2012 at 05:29:50PM +0200, Daniel Kiper wrote: > > On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: > > > > > > > > > ----- Original Message ----- > > > > Hi, > > > > > > > > It looks that Xen support for crash have not been maintained > > > > since 2009. I am trying to fix this. Here it is small > > > > bundle of fixes: > > > > - xen: Always calculate max_cpus value, > > > > - xen: Read only crash notes for onlined CPUs, > > > > - x86/xen: Read variables from dynamically allocated per_cpu > > > > data, > > > > - xen: Get idle data from alternative source, > > > > - xen: Read data correctly from dynamically allocated console > > > > ring > > > > too. > > > > > > > > Daniel > > > > > > Daniel, > > > > > > Can you absolutely confirm that these changes are all > > > backwards-compatible? > > > > I have not done tests with older versions of Xen. However, > > I made all patches with backward compatibility in mind. Anyway, > > If you wish I could do tests with let''s say Xen Ver. 3.4 > > and Xen Linux Kernel Ver. 2.6.18 at least. > > I think Dave is worried about it breaking with the version that is bundled > with RHEL5U8?Correct... Dave
----- Original Message -----> > > ----- Original Message ----- > > On Thu, Jul 05, 2012 at 05:29:50PM +0200, Daniel Kiper wrote: > > > On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > Hi, > > > > > > > > > > It looks that Xen support for crash have not been maintained > > > > > since 2009. I am trying to fix this. Here it is small > > > > > bundle of fixes: > > > > > - xen: Always calculate max_cpus value, > > > > > - xen: Read only crash notes for onlined CPUs, > > > > > - x86/xen: Read variables from dynamically allocated > > > > > per_cpu > > > > > data, > > > > > - xen: Get idle data from alternative source, > > > > > - xen: Read data correctly from dynamically allocated > > > > > console > > > > > ring > > > > > too. > > > > > > > > > > Daniel > > > > > > > > Daniel, > > > > > > > > Can you absolutely confirm that these changes are all > > > > backwards-compatible? > > > > > > I have not done tests with older versions of Xen. However, > > > I made all patches with backward compatibility in mind. Anyway, > > > If you wish I could do tests with let''s say Xen Ver. 3.4 > > > and Xen Linux Kernel Ver. 2.6.18 at least. > > > > I think Dave is worried about it breaking with the version that is bundled > > with RHEL5U8? > > Correct... > > Dave >And as it turns out, it does break RHEL5 xen, at least the changes you made for the log command: crash> log log: invalid kernel virtual address: 616e69625f64616f type: "conring contents" crash> Dave
On Thu, Jul 05, 2012 at 04:56:39PM +0100, Jan Beulich wrote:> >>> On 05.07.12 at 17:00, Daniel Kiper <daniel.kiper@oracle.com> wrote: > > max_cpus is not available since 20374 changeset (Miscellaneous data > > placement adjustments). It was moved to __initdata section. This section > > is freed after Xen initialization. Assume that max_cpus is always > > equal to XEN_HYPER_SIZE(cpumask_t) * 8. > > Using nr_cpu_ids, when available, would seem a better fit. AndHmmm... I could not find such animal in Xen source code. However, maybe I missed something.> I donm''t see why, on dumps from old hypervisors, you wouldn''t > want to continue using max_cpus. Oh, wait, I see - you would > have to be able to tell whether it actually sits in .init.data, which > might not be strait forward.Yep, but I will try to improve that once again. Daniel
On 13/07/12 14:19, Daniel Kiper wrote:> On Thu, Jul 05, 2012 at 04:56:39PM +0100, Jan Beulich wrote: >>>>> On 05.07.12 at 17:00, Daniel Kiper <daniel.kiper@oracle.com> wrote: >>> max_cpus is not available since 20374 changeset (Miscellaneous data >>> placement adjustments). It was moved to __initdata section. This section >>> is freed after Xen initialization. Assume that max_cpus is always >>> equal to XEN_HYPER_SIZE(cpumask_t) * 8. >> Using nr_cpu_ids, when available, would seem a better fit. And > Hmmm... I could not find such animal in Xen source code. > However, maybe I missed something.nr_cpu_ids was introduced into xen-unstable with c/s 23982:511d5e65a302 It is not present in 4.1 or earlier. ~Andrew> >> I donm''t see why, on dumps from old hypervisors, you wouldn''t >> want to continue using max_cpus. Oh, wait, I see - you would >> have to be able to tell whether it actually sits in .init.data, which >> might not be strait forward. > Yep, but I will try to improve that once again. > > Daniel-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com