9:19 a.m.
The 'vcpu' field changed from a fixed array to a pointer to an array. Change
xen_hyper_store_domain_context to account for this change.
Signed-off-by: Petr Tesarik <ptesarik(a)suse.cz>
---
xen_hyper.c | 40 +++++++++++++++++++++++++++++++++++++---
xen_hyper_defs.h | 1 +
2 files changed, 38 insertions(+), 3 deletions(-)
--- a/xen_hyper.c
+++ b/xen_hyper.c
@@ -219,6 +219,7 @@ xen_hyper_domain_init(void)
XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shutting_down, "domain",
"is_shutting_down");
XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shut_down, "domain",
"is_shut_down");
XEN_HYPER_MEMBER_OFFSET_INIT(domain_vcpu, "domain", "vcpu");
+ XEN_HYPER_MEMBER_OFFSET_INIT(domain_max_vcpus, "domain",
"max_vcpus");
XEN_HYPER_MEMBER_OFFSET_INIT(domain_arch, "domain", "arch");
XEN_HYPER_STRUCT_SIZE_INIT(arch_shared_info, "arch_shared_info");
@@ -1207,6 +1208,8 @@ struct xen_hyper_domain_context *
xen_hyper_store_domain_context(struct xen_hyper_domain_context *dc,
ulong domain, char *dp)
{
+ unsigned int max_vcpus;
+ char *vcpup;
int i;
dc->domain = domain;
@@ -1244,9 +1247,40 @@ xen_hyper_store_domain_context(struct xe
dc->domain_flags = XEN_HYPER_DOMF_ERROR;
}
dc->evtchn = ULONG(dp + XEN_HYPER_OFFSET(domain_evtchn));
- for (i = 0; i < XEN_HYPER_MAX_VIRT_CPUS; i++) {
- dc->vcpu[i] = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu) + i*sizeof(void *));
- if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
+
+ if (XEN_HYPER_VALID_MEMBER(domain_max_vcpus)) {
+ max_vcpus = UINT(dp + XEN_HYPER_OFFSET(domain_max_vcpus));
+ } else {
+ max_vcpus = XEN_HYPER_MAX_VIRT_CPUS;
+ }
+ if (MEMBER_TYPE("domain", "vcpu") == TYPE_CODE_ARRAY)
+ vcpup = dp + XEN_HYPER_OFFSET(domain_vcpu);
+ else {
+ ulong vcpu_array = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu));
+ if (vcpu_array && max_vcpus) {
+ if (!(vcpup =
+ malloc(max_vcpus * sizeof(void *)))) {
+ error(FATAL, "cannot malloc VCPU array for domain %lx.",
+ domain);
+ }
+ if (!readmem(vcpu_array, KVADDR,
+ vcpup, max_vcpus * sizeof(void*),
+ "VCPU array", RETURN_ON_ERROR)) {
+ error(FATAL, "cannot read VCPU array for domain %lx.",
+ domain);
+ }
+ } else {
+ vcpup = NULL;
+ }
+ }
+ if (vcpup) {
+ for (i = 0; i < max_vcpus; i++) {
+ dc->vcpu[i] = ULONG(vcpup + i*sizeof(void *));
+ if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
+ }
+ if (vcpup != dp + XEN_HYPER_OFFSET(domain_vcpu)) {
+ free(vcpup);
+ }
}
return dc;
--- a/xen_hyper_defs.h
+++ b/xen_hyper_defs.h
@@ -674,6 +674,7 @@ struct xen_hyper_offset_table {
long domain_is_shutting_down;
long domain_is_shut_down;
long domain_vcpu;
+ long domain_max_vcpus;
long domain_arch;
#ifdef IA64
/* mm_struct */
9:27 a.m.
New subject: [PATCH] Account for the changed type of the domain.vcpu field in Xen4
----- Original Message -----
The 'vcpu' field changed from a fixed array to a pointer to
an array. Change
xen_hyper_store_domain_context to account for this change.
Presuming this tests OK on older hypervisor dumps, this looks OK.
Queued for the next release based upon testing.
Thanks,
Dave
Signed-off-by: Petr Tesarik <ptesarik(a)suse.cz>
---
xen_hyper.c | 40 +++++++++++++++++++++++++++++++++++++---
xen_hyper_defs.h | 1 +
2 files changed, 38 insertions(+), 3 deletions(-)
--- a/xen_hyper.c
+++ b/xen_hyper.c
@@ -219,6 +219,7 @@ xen_hyper_domain_init(void)
XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shutting_down, "domain",
"is_shutting_down");
XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shut_down, "domain",
"is_shut_down");
XEN_HYPER_MEMBER_OFFSET_INIT(domain_vcpu, "domain", "vcpu");
+ XEN_HYPER_MEMBER_OFFSET_INIT(domain_max_vcpus, "domain",
"max_vcpus");
XEN_HYPER_MEMBER_OFFSET_INIT(domain_arch, "domain", "arch");
XEN_HYPER_STRUCT_SIZE_INIT(arch_shared_info, "arch_shared_info");
@@ -1207,6 +1208,8 @@ struct xen_hyper_domain_context *
xen_hyper_store_domain_context(struct xen_hyper_domain_context *dc,
ulong domain, char *dp)
{
+ unsigned int max_vcpus;
+ char *vcpup;
int i;
dc->domain = domain;
@@ -1244,9 +1247,40 @@ xen_hyper_store_domain_context(struct xe
dc->domain_flags = XEN_HYPER_DOMF_ERROR;
}
dc->evtchn = ULONG(dp + XEN_HYPER_OFFSET(domain_evtchn));
- for (i = 0; i < XEN_HYPER_MAX_VIRT_CPUS; i++) {
- dc->vcpu[i] = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu) +
i*sizeof(void *));
- if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
+
+ if (XEN_HYPER_VALID_MEMBER(domain_max_vcpus)) {
+ max_vcpus = UINT(dp + XEN_HYPER_OFFSET(domain_max_vcpus));
+ } else {
+ max_vcpus = XEN_HYPER_MAX_VIRT_CPUS;
+ }
+ if (MEMBER_TYPE("domain", "vcpu") == TYPE_CODE_ARRAY)
+ vcpup = dp + XEN_HYPER_OFFSET(domain_vcpu);
+ else {
+ ulong vcpu_array = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu));
+ if (vcpu_array && max_vcpus) {
+ if (!(vcpup =
+ malloc(max_vcpus * sizeof(void *)))) {
+ error(FATAL, "cannot malloc VCPU array for domain %lx.",
+ domain);
+ }
+ if (!readmem(vcpu_array, KVADDR,
+ vcpup, max_vcpus * sizeof(void*),
+ "VCPU array", RETURN_ON_ERROR)) {
+ error(FATAL, "cannot read VCPU array for domain %lx.",
+ domain);
+ }
+ } else {
+ vcpup = NULL;
+ }
+ }
+ if (vcpup) {
+ for (i = 0; i < max_vcpus; i++) {
+ dc->vcpu[i] = ULONG(vcpup + i*sizeof(void *));
+ if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
+ }
+ if (vcpup != dp + XEN_HYPER_OFFSET(domain_vcpu)) {
+ free(vcpup);
+ }
}
return dc;
--- a/xen_hyper_defs.h
+++ b/xen_hyper_defs.h
@@ -674,6 +674,7 @@ struct xen_hyper_offset_table {
long domain_is_shutting_down;
long domain_is_shut_down;
long domain_vcpu;
+ long domain_max_vcpus;
long domain_arch;
#ifdef IA64
/* mm_struct */
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
9:39 a.m.
New subject: [PATCH] Account for the changed type of the domain.vcpu field in Xen4
On Friday 07 of January 2011 16:27:55 Dave Anderson wrote:
----- Original Message -----
> The 'vcpu' field changed from a fixed array to a pointer to an array.
> Change xen_hyper_store_domain_context to account for this change.
Presuming this tests OK on older hypervisor dumps, this looks OK.
Queued for the next release based upon testing.
Hi Dave,
older Xen hypervisors didn't have the "max_vcpus" field in struct domain, so
there is in fact no change for them.
However, thinking about it some more, this might be affected by the increase
of XEN_HYPER_MAX_VIRT_CPUS. Although I haven't seen a failure, let me check
first whether a crash session on a dump from Xen 3.3 attempts to read past
array boundaries.
Petr Tesarik
SUSE Linux
Thanks,
Dave
> Signed-off-by: Petr Tesarik <ptesarik(a)suse.cz>
> ---
> xen_hyper.c | 40 +++++++++++++++++++++++++++++++++++++---
> xen_hyper_defs.h | 1 +
> 2 files changed, 38 insertions(+), 3 deletions(-)
>
> --- a/xen_hyper.c
> +++ b/xen_hyper.c
> @@ -219,6 +219,7 @@ xen_hyper_domain_init(void)
>
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shutting_down, "domain",
> "is_shutting_down");
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shut_down, "domain",
> "is_shut_down");
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_vcpu, "domain", "vcpu");
> + XEN_HYPER_MEMBER_OFFSET_INIT(domain_max_vcpus, "domain",
> "max_vcpus");
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_arch, "domain", "arch");
>
> XEN_HYPER_STRUCT_SIZE_INIT(arch_shared_info, "arch_shared_info");
> @@ -1207,6 +1208,8 @@ struct xen_hyper_domain_context *
> xen_hyper_store_domain_context(struct xen_hyper_domain_context *dc,
> ulong domain, char *dp)
> {
> + unsigned int max_vcpus;
> + char *vcpup;
> int i;
>
> dc->domain = domain;
> @@ -1244,9 +1247,40 @@ xen_hyper_store_domain_context(struct xe
> dc->domain_flags = XEN_HYPER_DOMF_ERROR;
> }
> dc->evtchn = ULONG(dp + XEN_HYPER_OFFSET(domain_evtchn));
> - for (i = 0; i < XEN_HYPER_MAX_VIRT_CPUS; i++) {
> - dc->vcpu[i] = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu) +
> i*sizeof(void *));
> - if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
> +
> + if (XEN_HYPER_VALID_MEMBER(domain_max_vcpus)) {
> + max_vcpus = UINT(dp + XEN_HYPER_OFFSET(domain_max_vcpus));
> + } else {
> + max_vcpus = XEN_HYPER_MAX_VIRT_CPUS;
> + }
> + if (MEMBER_TYPE("domain", "vcpu") == TYPE_CODE_ARRAY)
> + vcpup = dp + XEN_HYPER_OFFSET(domain_vcpu);
> + else {
> + ulong vcpu_array = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu));
> + if (vcpu_array && max_vcpus) {
> + if (!(vcpup =
> + malloc(max_vcpus * sizeof(void *)))) {
> + error(FATAL, "cannot malloc VCPU array for domain %lx.",
> + domain);
> + }
> + if (!readmem(vcpu_array, KVADDR,
> + vcpup, max_vcpus * sizeof(void*),
> + "VCPU array", RETURN_ON_ERROR)) {
> + error(FATAL, "cannot read VCPU array for domain %lx.",
> + domain);
> + }
> + } else {
> + vcpup = NULL;
> + }
> + }
> + if (vcpup) {
> + for (i = 0; i < max_vcpus; i++) {
> + dc->vcpu[i] = ULONG(vcpup + i*sizeof(void *));
> + if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
> + }
> + if (vcpup != dp + XEN_HYPER_OFFSET(domain_vcpu)) {
> + free(vcpup);
> + }
> }
>
> return dc;
> --- a/xen_hyper_defs.h
> +++ b/xen_hyper_defs.h
> @@ -674,6 +674,7 @@ struct xen_hyper_offset_table {
> long domain_is_shutting_down;
> long domain_is_shut_down;
> long domain_vcpu;
> + long domain_max_vcpus;
> long domain_arch;
> #ifdef IA64
> /* mm_struct */
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
9:43 a.m.
New subject: [PATCH] Account for the changed type of the domain.vcpu field in Xen4
----- Original Message -----
On Friday 07 of January 2011 16:27:55 Dave Anderson wrote:
> ----- Original Message -----
>
> > The 'vcpu' field changed from a fixed array to a pointer to an array.
> > Change xen_hyper_store_domain_context to account for this change.
>
> Presuming this tests OK on older hypervisor dumps, this looks OK.
> Queued for the next release based upon testing.
Hi Dave,
older Xen hypervisors didn't have the "max_vcpus" field in struct domain,
so
there is in fact no change for them.
However, thinking about it some more, this might be affected by the increase
of XEN_HYPER_MAX_VIRT_CPUS. Although I haven't seen a failure, let me check
first whether a crash session on a dump from Xen 3.3 attempts to read past
array boundaries.
Ah, OK, I appreciate that. Is it something that can be segregated
by the xen version (like the virtual address change)? That would
make me feel much warmer and fuzzier...
Dave
Petr Tesarik
SUSE Linux
> Thanks,
> Dave
>
> > Signed-off-by: Petr Tesarik <ptesarik(a)suse.cz>
> > ---
> > xen_hyper.c | 40 +++++++++++++++++++++++++++++++++++++---
> > xen_hyper_defs.h | 1 +
> > 2 files changed, 38 insertions(+), 3 deletions(-)
> >
> > --- a/xen_hyper.c
> > +++ b/xen_hyper.c
> > @@ -219,6 +219,7 @@ xen_hyper_domain_init(void)
> >
> > XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shutting_down, "domain",
> > "is_shutting_down");
> > XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shut_down, "domain",
> > "is_shut_down");
> > XEN_HYPER_MEMBER_OFFSET_INIT(domain_vcpu, "domain",
"vcpu");
> > + XEN_HYPER_MEMBER_OFFSET_INIT(domain_max_vcpus, "domain",
> > "max_vcpus");
> > XEN_HYPER_MEMBER_OFFSET_INIT(domain_arch, "domain",
"arch");
> >
> > XEN_HYPER_STRUCT_SIZE_INIT(arch_shared_info, "arch_shared_info");
> > @@ -1207,6 +1208,8 @@ struct xen_hyper_domain_context *
> > xen_hyper_store_domain_context(struct xen_hyper_domain_context
> > *dc,
> > ulong domain, char *dp)
> > {
> > + unsigned int max_vcpus;
> > + char *vcpup;
> > int i;
> >
> > dc->domain = domain;
> > @@ -1244,9 +1247,40 @@ xen_hyper_store_domain_context(struct xe
> > dc->domain_flags = XEN_HYPER_DOMF_ERROR;
> > }
> > dc->evtchn = ULONG(dp + XEN_HYPER_OFFSET(domain_evtchn));
> > - for (i = 0; i < XEN_HYPER_MAX_VIRT_CPUS; i++) {
> > - dc->vcpu[i] = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu) +
> > i*sizeof(void *));
> > - if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
> > +
> > + if (XEN_HYPER_VALID_MEMBER(domain_max_vcpus)) {
> > + max_vcpus = UINT(dp + XEN_HYPER_OFFSET(domain_max_vcpus));
> > + } else {
> > + max_vcpus = XEN_HYPER_MAX_VIRT_CPUS;
> > + }
> > + if (MEMBER_TYPE("domain", "vcpu") == TYPE_CODE_ARRAY)
> > + vcpup = dp + XEN_HYPER_OFFSET(domain_vcpu);
> > + else {
> > + ulong vcpu_array = ULONG(dp + XEN_HYPER_OFFSET(domain_vcpu));
> > + if (vcpu_array && max_vcpus) {
> > + if (!(vcpup =
> > + malloc(max_vcpus * sizeof(void *)))) {
> > + error(FATAL, "cannot malloc VCPU array for domain %lx.",
> > + domain);
> > + }
> > + if (!readmem(vcpu_array, KVADDR,
> > + vcpup, max_vcpus * sizeof(void*),
> > + "VCPU array", RETURN_ON_ERROR)) {
> > + error(FATAL, "cannot read VCPU array for domain %lx.",
> > + domain);
> > + }
> > + } else {
> > + vcpup = NULL;
> > + }
> > + }
> > + if (vcpup) {
> > + for (i = 0; i < max_vcpus; i++) {
> > + dc->vcpu[i] = ULONG(vcpup + i*sizeof(void *));
> > + if (dc->vcpu[i]) XEN_HYPER_NR_VCPUS_IN_DOM(dc)++;
> > + }
> > + if (vcpup != dp + XEN_HYPER_OFFSET(domain_vcpu)) {
> > + free(vcpup);
> > + }
> > }
> >
> > return dc;
> > --- a/xen_hyper_defs.h
> > +++ b/xen_hyper_defs.h
> > @@ -674,6 +674,7 @@ struct xen_hyper_offset_table {
> > long domain_is_shutting_down;
> > long domain_is_shut_down;
> > long domain_vcpu;
> > + long domain_max_vcpus;
> > long domain_arch;
> > #ifdef IA64
> > /* mm_struct */
> >
> > --
> > Crash-utility mailing list
> > Crash-utility(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
1:18 p.m.
New subject: [PATCH] Account for the changed type of the domain.vcpu field in Xen4
----- Original Message -----
On Friday 07 of January 2011 16:27:55 Dave Anderson wrote:
> ----- Original Message -----
>
> > The 'vcpu' field changed from a fixed array to a pointer to an array.
> > Change xen_hyper_store_domain_context to account for this change.
>
> Presuming this tests OK on older hypervisor dumps, this looks OK.
> Queued for the next release based upon testing.
Hi Dave,
older Xen hypervisors didn't have the "max_vcpus" field in struct domain,
so
there is in fact no change for them.
However, thinking about it some more, this might be affected by the increase
of XEN_HYPER_MAX_VIRT_CPUS. Although I haven't seen a failure, let me check
first whether a crash session on a dump from Xen 3.3 attempts to read past
array boundaries.
As it turns out, my tests didn't work out on any of my sample hypervisor dumps,
presumably due to this patch, the XEN_HYPER_MAX_VIRT_CPUS patch, or both (?).
As one example, here's what the invocation, and then the "vcpus" command,
look like
with crash-5.1.1:
crash 5.1.1
Copyright (C) 2002-2010 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
KERNEL: xen-syms-2.6.18-89.el5
DEBUGINFO: ./xen-syms-2.6.18-89.el5.debug
DUMPFILE: xen-5.2-x86_64-vmcore
CPUS: 4
DOMAINS: 4
UPTIME: 00:01:36
MACHINE: Dual-Core AMD Opteron(tm) Processor 2218 (2600 Mhz)
MEMORY: 1 GB
PCPU-ID: 0
PCPU: ffff828c80217f28
VCPU-ID: 0
VCPU: ffff83003f01e080 (VCPU_RUNNING)
DOMAIN-ID: 0
DOMAIN: ffff83003f202080 (DOMAIN_RUNNING)
STATE: CRASH
crash> vcpus
VCID PCID VCPU ST T DOMID DOMAIN
0 0 ffff83003f002080 RU I 32767 ffff83003f25a080
1 1 ffff83003f208080 RU I 32767 ffff83003f25a080
2 2 ffff83003f25c080 RU I 32767 ffff83003f25a080
3 3 ffff83003fff8080 RU I 32767 ffff83003f25a080
* 0 0 ffff83003f01e080 RU 0 0 ffff83003f202080
1 1
ffff83003f01c080 BL 0 0 ffff83003f202080
2 2 ffff83003f01a080 BL 0 0 ffff83003f202080
3 3 ffff83003f018080 BL 0 0 ffff83003f202080
crash>
Here's with your patches applied:
crash 5.1.1
Copyright (C) 2002-2010 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
... [ repeats ~7000 times ] ...
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
crash: invalid kernel virtual address: 0 type: "fill_vcpu_struct"
WARNING: cannot fill vcpu struct.
KERNEL: xen-syms-2.6.18-89.el5
DEBUGINFO: ./xen-syms-2.6.18-89.el5.debug
DUMPFILE: xen-5.2-x86_64-vmcore
CPUS: 4
DOMAINS: 4
UPTIME: 00:01:36
MACHINE: Dual-Core AMD Opteron(tm) Processor 2218 (2600 Mhz)
MEMORY: 1 GB
PCPU-ID: 0
PCPU: ffff828c80217f28
VCPU-ID: 0
VCPU: ffff83003f01e080 (VCPU_RUNNING)
DOMAIN-ID: 0
DOMAIN: ffff83003f202080 (DOMAIN_RUNNING)
STATE: CRASH
crash> vcpus
VCID PCID VCPU ST T DOMID DOMAIN
WARNING: cannot get context from domain address.
-1363873424 63 1101 RU ????? 0
WARNING: cannot get context from domain address.
-1363873424 63 3faeb4f020 RU ????? 0
WARNING: cannot get context from domain address.
-1363873424 63 3faeb4f020 RU ????? 0
WARNING: cannot get context from domain address.
-1363873424 63 1101 RU ????? 0
WARNING: cannot get context from domain address.
-1363873424 63 3faeb4f020 RU ????? 0
WARNING: cannot get context from domain address.
-1363873424 63 3faeb4f020 RU ????? 0
0 0 ffff83003f002080 RU I 32767 ffff83003f25a080
1 1 ffff83003f208080 RU I 32767 ffff83003f25a080
2 2 ffff83003f25c080 RU I 32767 ffff83003f25a080
3 3 ffff83003fff8080 RU I 32767 ffff83003f25a080
WARNING: cannot get
context from domain address.
0 0 ffff83003fffc000 RU ????? 0
WARNING: cannot get context from domain address.
1073725539 0 ffff83003df5b000 RU ????? 0
WARNING: cannot get context from domain address.
1039511651 0 ffff83003df5a000 RU ????? 0
WARNING: cannot get context from domain address.
1039511651 0 f5800000 RU ????? 0
WARNING: cannot get context from domain address.
1039511651 0 ffffffff00ff0001 RU ????? 0
WARNING: cannot get context from domain address.
1868722030 536901988 ffff828c80193ae3 ?? ????? 7473697373612067
WARNING: cannot get context from domain address.
1059435008 -32000 ffff83003f25b200 RU ????? ffff83003f25b210
WARNING: cannot get context from domain address.
1059435008 -32000 ffff83003f25b200 RU ????? ffff83003f25b210
WARNING: cannot get context from domain address.
1059435024 -32000 ffff83003f25b210 RU ????? ffff83003f25b220
WARNING: cannot get context from domain address.
1059435024 -32000 ffff83003f25b210 RU ????? ffff83003f25b220
WARNING: cannot get context from domain address.
1059435040 -32000 ffff83003f25b220 ?? ????? ffff83003f25b230
WARNING: cannot get context from domain address.
1059435040 -32000 ffff83003f25b220 ?? ????? ffff83003f25b230
WARNING: cannot get context from domain address.
1059435056 -32000 ffff83003f25b230 ?? ????? ffff83003f25b240
WARNING: cannot get context from domain address.
1059435056 -32000 ffff83003f25b230 ?? ????? ffff83003f25b240
WARNING: cannot get context from domain address.
1059435072 -32000 ffff83003f25b240 ?? ????? 0
WARNING: cannot get context from domain address.
1059435072 -32000 ffff83003f25b240 ?? ????? 0
WARNING: cannot get context from domain address.
1059435072 -32000 ffffffff00ff0001 ?? ????? 0
WARNING: cannot get context from domain address.
1868722030 536901988 ffff828c80193ae3 ?? ????? 7473697373612067
WARNING: cannot get context from domain address.
-976795563 -32768 ffff828c8016a400 ?? ????? 8348fb8948530000
WARNING: cannot get context from domain address.
-976795563 -32768 ffff828c8016a2a0 ?? ????? 8348fb8948530000
WARNING: cannot get context from domain address.
418153288 610044232 ffff828c80168c30 ?? ????? e52148ffff8000c5
WARNING: cannot get context from domain address.
418153288 610044232 ffffffff00ff0001 ?? ????? e52148ffff8000c5
WARNING: cannot get context from domain address.
1868722030 536901988 ffff828c80193ae3 ?? ????? 7473697373612067
WARNING: cannot get context from domain address.
1059435248 -32000 ffff83003f25b2f0 RU ????? 0
WARNING: cannot get context from domain address.
1059435248 -32000 ffff83003f25b2f0 RU ????? 0
WARNING: cannot get context from domain address.
1059435248 -32000 1101 RU ????? 0
WARNING: cannot get context from domain address.
1059435248 -32000 3faeb4f020 RU ????? 0
WARNING: cannot get context from domain address.
1059435248 -32000 3faeb4f020 RU ????? 0
* 0 0 ffff83003f01e080 RU 0 0 ffff83003f202080
1 1 ffff83003f01c080 BL 0 0 ffff83003f202080
2 2 ffff83003f01a080 BL 0 0 ffff83003f202080
3 3 ffff83003f018080 BL 0 0 ffff83003f202080
3 3 f BL 0 0 ffff83003f202080
WARNING: cannot get context from domain address.
979304547 0 ffff83003ffe0000 RU ????? 0
WARNING: cannot get context from domain address.
1073610851 0 ffff83003df59000 RU ????? 0
WARNING: cannot get context from domain address.
1039503459 0 ffff83003df58000 RU ????? 0
WARNING: cannot get context from domain address.
1039503459 0 f5800000 RU ????? 0
1059070176 -32000 ffff83003ffe8a80 ?? 0 0 ffff83003f202080
1059070176 -32000 9af910b0 ?? 0 0 ffff83003f202080
1059070176 -32000 10000 ?? 0 0 ffff83003f202080
1059070176 -32000 100ff0000000000 ?? 0 0 ffff83003f202080
1059070176 -32000 10000 ?? 0 0 ffff83003f202080
1059070176 -32000 100ff0000000000 ?? 0 0 ffff83003f202080
1059070176 -32000 10000 ?? 0 0 ffff83003f202080
1059070176 -32000 ff0000000000 ?? 0 0 ffff83003f202080
1059070176 -32000 56a4591b ?? 0 0 ffff83003f202080
1059070176 -32000 56a45cf0 ?? 0 0 ffff83003f202080
1059070176 -32000 56a45d07 ?? 0 0 ffff83003f202080
1059070176 -32000 ff0001 ?? 0 0 ffff83003f202080
1059070176 -32000 2 ?? 0 0 ffff83003f202080
1059070176 -32000 40 ?? 0 0 ffff83003f202080
1059070176 -32000 4 ?? 0 0 ffff83003f202080
WARNING: cannot get context from domain address.
955024200 12633928 ffff828c8014a460 ?? ????? fb894810246c8948
WARNING: cannot get context from domain address.
955024200 12633928 61 ?? ????? fb894810246c8948
WARNING: cannot get context from domain address.
955024200 12633928 1 ?? ????? fb894810246c8948
WARNING: cannot get context from domain address.
955024200 12633928 ffff828c8014a760 ?? ????? fd894808245c8948
WARNING: cannot get context from domain address.
955024200 12633928 ffffffff00ff0001 ?? ????? fd894808245c8948
WARNING: cannot get context from domain address.
1868722030 536901988 ffff828c80193ae3 ?? ????? 7473697373612067
WARNING: cannot get context from domain address.
1059074560 -32000 ffff83003f203200 RU ????? ffff83003f203210
WARNING: cannot get context from domain address.
1059074560 -32000 ffff83003f203200 RU ????? ffff83003f203210
WARNING: cannot get context from domain address.
1059074576 -32000 ffff83003f203210 RU ????? ffff83003f203220
WARNING: cannot get context from domain address.
1059074576 -32000 ffff83003f203210 RU ????? ffff83003f203220
WARNING: cannot get context from domain address.
1059074592 -32000 ffff83003f203220 ?? ????? ffff83003f203230
WARNING: cannot get context from domain address.
1059074592 -32000 ffff83003f203220 ?? ????? ffff83003f203230
WARNING: cannot get context from domain address.
1059074608 -32000 ffff83003f203230 ?? ????? ffff83003f203240
WARNING: cannot get context from domain address.
1059074608 -32000 ffff83003f203230 ?? ????? ffff83003f203240
WARNING: cannot get context from domain address.
1059074624 -32000 ffff83003f203240 ?? ????? 0
WARNING: cannot get context from domain address.
1059074624 -32000 ffff83003f203240 ?? ????? 0
WARNING: cannot get context from domain address.
1059074624 -32000 ffffffff00ff0001 ?? ????? 0
WARNING: cannot get context from domain address.
1868722030 536901988 ffff828c80193ae3 ?? ????? 7473697373612067
WARNING: cannot get context from domain address.
-976795563 -32768 ffff828c8016a400 ?? ????? 8348fb8948530000
WARNING: cannot get context from domain address.
-976795563 -32768 ffff828c8016a2a0 ?? ????? 8348fb8948530000
WARNING: cannot get context from domain address.
418153288 610044232 ffff828c80168c30 ?? ????? e52148ffff8000c5
WARNING: cannot get context from domain address.
418153288 610044232 ffffffff00ff0001 ?? ????? e52148ffff8000c5
WARNING: cannot get context from domain address.
1868722030 536901988 ffff828c80193ae3 ?? ????? 7473697373612067
WARNING: cannot get context from domain address.
1059074800 -32000 ffff83003f2032f0 RU ????? 0
WARNING: cannot get context from domain address.
1059074800 -32000 ffff83003f2032f0 RU ????? 0
WARNING: cannot get context from domain address.
1059074800 -32000 1101 RU ????? 0
WARNING: cannot get context from domain address.
1059074800 -32000 3faeb4f020 RU ????? 0
WARNING: cannot get context from domain address.
1059074800 -32000 3faeb4f020 RU ????? 0
crash>
The same kind of thing happens with all my sample dumpfiles.
I did have to remove a couple superfluous lines from the 3rd (init_tss) and
5th (domain.vcpu) patches, but they shouldn't have any bearing:
# diff init_tss.patch 3.patch
10d9
< XEN_HYPER_MEMBER_OFFSET_INIT(cpu_info_guest_cpu_user_regs, "cpu_info",
"guest_cpu_user_regs");
12d10
< XEN_HYPER_MEMBER_OFFSET_INIT(cpu_info_processor_id, "cpu_info",
"processor_id");
# diff domain_vcpu.patch 5.patch
5d4
< XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shutting_down, "domain",
"is_shutting_down");
#
Anyway, I didn't look into this at all, but I'm going to hold all 5 patches
until this gets resolved. If you want, I can make the xen-syms/vmcore pair
available.
Thanks,
Dave
7:53 a.m.
Dne pátek 07 Leden 2011 20:18:29 Dave Anderson napsal(a):
----- Original Message -----
> On Friday 07 of January 2011 16:27:55 Dave Anderson wrote:
> > ----- Original Message -----
> >
> > > The 'vcpu' field changed from a fixed array to a pointer to an
array.
> > > Change xen_hyper_store_domain_context to account for this change.
> >
> > Presuming this tests OK on older hypervisor dumps, this looks OK.
> > Queued for the next release based upon testing.
>
> Hi Dave,
>
> older Xen hypervisors didn't have the "max_vcpus" field in struct
domain,
> so there is in fact no change for them.
>
> However, thinking about it some more, this might be affected by the
> increase of XEN_HYPER_MAX_VIRT_CPUS. Although I haven't seen a failure,
> let me check first whether a crash session on a dump from Xen 3.3
> attempts to read past array boundaries.
As it turns out, my tests didn't work out on any of my sample hypervisor
dumps, presumably due to this patch, the XEN_HYPER_MAX_VIRT_CPUS patch, or
both (?).
Hi Dave,
yes, it's because of the XEN_HYPER_MAX_VIRT_CPUS. The vcpu field is declared
as:
struct vcpu *vcpu[MAX_VIRT_CPUS];
for Xen-3.3, but it is a pointer to a dynamically allocated array in Xen4. So,
this is exactly what I was afraid of, and crash reads past the array
boundaries in xen_hyper_store_domain_context.
OTOH I don't like the idea of hard-wiring the MAX_VIRT_CPUS constant in crash,
because it's one of the easiest tweaks one could do on the Xen kernel (well,
32 VCPUs isn't really much).
Let me see if I can find a better solution,
Petr
4994
days inactive
5001
days old
devel@lists.crash-utility.osci.io
5 comments
2 participants
participants (2)
-
Dave Anderson -
Petr Tesarik