Mailing List Archive

Itsuro ODA wrote:
> Hi,
>
> This patch is for xen hypervisor analysis function of the
> crash command to apply to the xen-3.3.0 (the newest version of xen).
>
> * PERCPU_SHIFT becomes 13 (from 12) in the xen-3.3.0.
> This value is calculated from "__per_cpu_start" and "__per_cpu_data_end".
> * "jiffies" does not exist in the xen-3.3.0.
> It was used to show the uptime. I found there is no altanernative
> (i.e. the xen hypervisor does not have the uptime.).
> Then if "jiffies" does not exist, "--:--:--" is showed as UPTIME in
> the sys command.
> (Is it better to eliminate the whole UPTIME line ?)
> --- example ---
> crash> sys
> KERNEL: xen-syms
> DUMPFILE: vmcore
> CPUS: 4
> DOMAINS: 5
> UPTIME: --:--:--
> MACHINE: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2660 Mhz)
> MEMORY: 2 GB
> ----------------
>
> This patch is for crash-4.0-7.2.
>
> Thanks
> Itsuro Oda

The patch looks OK. But just for sanity's sake, is it guaranteed that
the per_cpu data section will be greater than 4k on both architectures?
Or could there be some combination of xen CONFIG options that could
reduce the i386 per_cpu data section contents to less than 4K even though
PERCPU_SHIFT is 13?

Dave

>
> ---
> --- xen_hyper_defs.h.org 2008-10-06 13:45:39.000000000 +0900
> +++ xen_hyper_defs.h 2008-10-06 13:44:44.000000000 +0900
> @@ -134,9 +134,8 @@
> #endif
>
> #if defined(X86) || defined(X86_64)
> -#define XEN_HYPER_PERCPU_SHIFT 12
> #define xen_hyper_per_cpu(var, cpu) \
> - ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT))
> + ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift))
> #elif defined(IA64)
> #define xen_hyper_per_cpu(var, cpu) \
> ((xht->flags & XEN_HYPER_SMP) ? \
> @@ -404,6 +403,7 @@
> ulong *cpumask;
> uint *cpu_idxs;
> ulong *__per_cpu_offset;
> + int percpu_shift;
> };
>
> struct xen_hyper_dumpinfo_context {
> --- xen_hyper.c.org 2008-10-06 13:41:14.000000000 +0900
> +++ xen_hyper.c 2008-10-06 14:15:03.000000000 +0900
> @@ -71,6 +71,8 @@
> #endif
>
> #if defined(X86) || defined(X86_64)
> + xht->percpu_shift =
> + (symbol_value("__per_cpu_data_end") - symbol_value("__per_cpu_start") > 4096) ? 13: 12;
> member_offset = MEMBER_OFFSET("cpuinfo_x86", "x86_model_id");
> buf = GETBUF(XEN_HYPER_SIZE(cpuinfo_x86));
> if (xen_hyper_test_pcpu_id(XEN_HYPER_CRASHING_CPU())) {
> @@ -1746,9 +1748,11 @@
> tmp2 = (ulong)jiffies_64;
> jiffies_64 = (ulonglong)(tmp2 - tmp1);
> }
> - } else {
> + } else if (symbol_exists("jiffies")) {
> get_symbol_data("jiffies", sizeof(long), &jiffies);
> jiffies_64 = (ulonglong)jiffies;
> + } else {
> + jiffies_64 = 0; /* hypervisor does not have uptime */
> }
>
> return jiffies_64;
> --- xen_hyper_command.c.org 2008-10-07 08:05:37.000000000 +0900
> +++ xen_hyper_command.c 2008-10-07 08:24:29.000000000 +0900
> @@ -1022,7 +1022,8 @@
> (buf1, "%d\n", XEN_HYPER_NR_DOMAINS()));
> /* !!!Display a date here if it can be found. */
> XEN_HYPER_PRI(fp, len, "UPTIME: ", buf1, flag,
> - (buf1, "%s\n", convert_time(xen_hyper_get_uptime_hyper(), buf2)));
> + (buf1, "%s\n", (xen_hyper_get_uptime_hyper() ?
> + convert_time(xen_hyper_get_uptime_hyper(), buf2) : "--:--:--")));
> /* !!!Display a version here if it can be found. */
> XEN_HYPER_PRI_CONST(fp, len, "MACHINE: ", flag);
> if (strlen(uts->machine)) {
> ---





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/10/08 14:39, "Dave Anderson" <anderson@redhat.com> wrote:

> The patch looks OK. But just for sanity's sake, is it guaranteed that
> the per_cpu data section will be greater than 4k on both architectures?
> Or could there be some combination of xen CONFIG options that could
> reduce the i386 per_cpu data section contents to less than 4K even though
> PERCPU_SHIFT is 13?

PERCPU_SHIFT has only ever been 12 or 13 so far, and it's unlikely to ever
get smaller. Ongoing, we could help you out by defining some useful label in
our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or
'__per_cpu_start + PERCPU_SHIFT', as I'm not sure about creating labels
outside the virtual address ranges defined by the object file).

-- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 7/10/08 14:39, "Dave Anderson" <anderson@redhat.com> wrote:
>
>> The patch looks OK. But just for sanity's sake, is it guaranteed that
>> the per_cpu data section will be greater than 4k on both architectures?
>> Or could there be some combination of xen CONFIG options that could
>> reduce the i386 per_cpu data section contents to less than 4K even though
>> PERCPU_SHIFT is 13?
>
> PERCPU_SHIFT has only ever been 12 or 13 so far, and it's unlikely to ever
> get smaller. Ongoing, we could help you out by defining some useful label in
> our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or
> '__per_cpu_start + PERCPU_SHIFT', as I'm not sure about creating labels
> outside the virtual address ranges defined by the object file).
>
> -- Keir

Yep, that's fine too, but for now Oda-san's patch will suffice now as
long as the smallest possible percpu data section on the x86 arch with
a PERCPU_SHIFT of 13 will always overflow into a space greater than 4k.
So I'm still curious, because I note that on a RHEL5 x86_64 hypervisor
the per-cpu data space is 1576 bytes, and presumably smaller on an x86.
Was there a new data structure that forced the issue? And does it force
the issue on both arches?

Dave






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/10/08 15:35, "Dave Anderson" <anderson@redhat.com> wrote:

>> PERCPU_SHIFT has only ever been 12 or 13 so far, and it's unlikely to ever
>> get smaller. Ongoing, we could help you out by defining some useful label in
>> our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or
>> '__per_cpu_start + PERCPU_SHIFT', as I'm not sure about creating labels
>> outside the virtual address ranges defined by the object file).
>>
>> -- Keir
>
> Yep, that's fine too, but for now Oda-san's patch will suffice now as
> long as the smallest possible percpu data section on the x86 arch with
> a PERCPU_SHIFT of 13 will always overflow into a space greater than 4k.
> So I'm still curious, because I note that on a RHEL5 x86_64 hypervisor
> the per-cpu data space is 1576 bytes, and presumably smaller on an x86.
> Was there a new data structure that forced the issue? And does it force
> the issue on both arches?

PERCPU_SHIFT has to be big enough that the per-cpu data area happens to be
smaller than 1<<PERCPU_SHIFT bytes. This relationship is not enforced at
build time but we BUG_ON() it early during boot. Indeed at some point during
3.3 development some big structs got dumped in the per-cpu area and
increased its size beyond 2^12. Hence we BUG()ed and hence we bumped to
2^13.

What this does mean is that we might, on some builds, actually have data
area < 4kB even while we have PERCPU_SHIFT==13. I think it's unlikely in
practice though since I believe we're well over the 4kB boundary now.

I don't think Xen/ia64 uses this same implementation technique. It's
probably more like Linux's percpu data area implementation.

-- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

It is a good question.
I checked about i386. __per_cpu_data_end - __per_cpu_start is smaller
than 4K, but PERCPU_SHIFT is 13 (it is common both x86_32 and x86_64).
Oops.

I will consider more.

Thanks
Itsuro Oda

On Tue, 07 Oct 2008 09:39:05 -0400
Dave Anderson <anderson@redhat.com> wrote:

> Itsuro ODA wrote:
> > Hi,
> >
> > This patch is for xen hypervisor analysis function of the
> > crash command to apply to the xen-3.3.0 (the newest version of xen).
> >
> > * PERCPU_SHIFT becomes 13 (from 12) in the xen-3.3.0.
> > This value is calculated from "__per_cpu_start" and "__per_cpu_data_end".
> > * "jiffies" does not exist in the xen-3.3.0.
> > It was used to show the uptime. I found there is no altanernative
> > (i.e. the xen hypervisor does not have the uptime.).
> > Then if "jiffies" does not exist, "--:--:--" is showed as UPTIME in
> > the sys command.
> > (Is it better to eliminate the whole UPTIME line ?)
> > --- example ---
> > crash> sys
> > KERNEL: xen-syms
> > DUMPFILE: vmcore
> > CPUS: 4
> > DOMAINS: 5
> > UPTIME: --:--:--
> > MACHINE: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2660 Mhz)
> > MEMORY: 2 GB
> > ----------------
> >
> > This patch is for crash-4.0-7.2.
> >
> > Thanks
> > Itsuro Oda
>
> The patch looks OK. But just for sanity's sake, is it guaranteed that
> the per_cpu data section will be greater than 4k on both architectures?
> Or could there be some combination of xen CONFIG options that could
> reduce the i386 per_cpu data section contents to less than 4K even though
> PERCPU_SHIFT is 13?
>
> Dave
>
> >
> > ---
> > --- xen_hyper_defs.h.org 2008-10-06 13:45:39.000000000 +0900
> > +++ xen_hyper_defs.h 2008-10-06 13:44:44.000000000 +0900
> > @@ -134,9 +134,8 @@
> > #endif
> >
> > #if defined(X86) || defined(X86_64)
> > -#define XEN_HYPER_PERCPU_SHIFT 12
> > #define xen_hyper_per_cpu(var, cpu) \
> > - ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT))
> > + ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift))
> > #elif defined(IA64)
> > #define xen_hyper_per_cpu(var, cpu) \
> > ((xht->flags & XEN_HYPER_SMP) ? \
> > @@ -404,6 +403,7 @@
> > ulong *cpumask;
> > uint *cpu_idxs;
> > ulong *__per_cpu_offset;
> > + int percpu_shift;
> > };
> >
> > struct xen_hyper_dumpinfo_context {
> > --- xen_hyper.c.org 2008-10-06 13:41:14.000000000 +0900
> > +++ xen_hyper.c 2008-10-06 14:15:03.000000000 +0900
> > @@ -71,6 +71,8 @@
> > #endif
> >
> > #if defined(X86) || defined(X86_64)
> > + xht->percpu_shift =
> > + (symbol_value("__per_cpu_data_end") - symbol_value("__per_cpu_start") > 4096) ? 13: 12;
> > member_offset = MEMBER_OFFSET("cpuinfo_x86", "x86_model_id");
> > buf = GETBUF(XEN_HYPER_SIZE(cpuinfo_x86));
> > if (xen_hyper_test_pcpu_id(XEN_HYPER_CRASHING_CPU())) {
> > @@ -1746,9 +1748,11 @@
> > tmp2 = (ulong)jiffies_64;
> > jiffies_64 = (ulonglong)(tmp2 - tmp1);
> > }
> > - } else {
> > + } else if (symbol_exists("jiffies")) {
> > get_symbol_data("jiffies", sizeof(long), &jiffies);
> > jiffies_64 = (ulonglong)jiffies;
> > + } else {
> > + jiffies_64 = 0; /* hypervisor does not have uptime */
> > }
> >
> > return jiffies_64;
> > --- xen_hyper_command.c.org 2008-10-07 08:05:37.000000000 +0900
> > +++ xen_hyper_command.c 2008-10-07 08:24:29.000000000 +0900
> > @@ -1022,7 +1022,8 @@
> > (buf1, "%d\n", XEN_HYPER_NR_DOMAINS()));
> > /* !!!Display a date here if it can be found. */
> > XEN_HYPER_PRI(fp, len, "UPTIME: ", buf1, flag,
> > - (buf1, "%s\n", convert_time(xen_hyper_get_uptime_hyper(), buf2)));
> > + (buf1, "%s\n", (xen_hyper_get_uptime_hyper() ?
> > + convert_time(xen_hyper_get_uptime_hyper(), buf2) : "--:--:--")));
> > /* !!!Display a version here if it can be found. */
> > XEN_HYPER_PRI_CONST(fp, len, "MACHINE: ", flag);
> > if (strlen(uts->machine)) {
> > ---
>
>
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Itsuro ODA <oda@valinux.co.jp>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

It is very helpful.

Thanks
Itsuro Oda

On Tue, 07 Oct 2008 14:55:00 +0100
Keir Fraser <keir.fraser@eu.citrix.com> wrote:

> On 7/10/08 14:39, "Dave Anderson" <anderson@redhat.com> wrote:
>
> > The patch looks OK. But just for sanity's sake, is it guaranteed that
> > the per_cpu data section will be greater than 4k on both architectures?
> > Or could there be some combination of xen CONFIG options that could
> > reduce the i386 per_cpu data section contents to less than 4K even though
> > PERCPU_SHIFT is 13?
>
> PERCPU_SHIFT has only ever been 12 or 13 so far, and it's unlikely to ever
> get smaller. Ongoing, we could help you out by defining some useful label in
> our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or
> '__per_cpu_start + PERCPU_SHIFT', as I'm not sure about creating labels
> outside the virtual address ranges defined by the object file).
>
> -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

--
Itsuro ODA <oda@valinux.co.jp>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

I decided to use the version number of xen which is included in the
XEN_ELFNOTE_CRASH_INFO after all.
The defect is that vmcores taken on the xen-unstable during the
xen-3.3 development before the changset 17831 (2008/6/12) can not be
analized with the newer crash. I think it is not a big problem since
it is rare case to analyze such vmcores right now.

On Wed, 8 Oct 2008 08:56:48 -0400 (EDT)
Dave Anderson <anderson@redhat.com> wrote:

>
> ----- "Itsuro ODA" <oda@valinux.co.jp> wrote:
>
> > Hi,
> >
> > It is a good question.
> > I checked about i386. __per_cpu_data_end - __per_cpu_start is smaller
> > than 4K, but PERCPU_SHIFT is 13 (it is common both x86_32 and
> > x86_64).
> > Oops.
> >
> > I will consider more.
>
> Ok, I'll wait for a new patch set.
>
> Another direction that you might consider is to check whether
> a new symbol was introduced in the same patch-set that
> incremented the PERCPU_SHIFT values?

I found this is equivalent as using "__per_cpu_data_end - __per_cpu_start > 4K"
since the change of the PERCPU_SHIFT was for x86_64 only and it was
not helpful for i386.

> Or take Keir up on his offer to compile-in an absolute
> value that can be accessed like a symbol?

It is checked first in the patch.

> As far as the UPTIME display, it will probably raise
> fewer questions in the future if you would just remove
> it entirely.
>
> Thanks,
> Dave
>

* PERCPU_SHIFT becomes 13 (from 12) in the xen-3.3.0.
This value is determined by xen version number.
(If the symbol "__per_cpu_shift" exists, it is used first for the future.)
* "jiffies" does not exist in the xen-3.3.0.
It was used to show the uptime. I found there is no altanernative
(i.e. the xen hypervisor does not have the uptime.).
Then if "jiffies" does not exist, "--:--:--" is showed as UPTIME in
the sys command.
--- example ---
crash> sys
KERNEL: xen-syms
DUMPFILE: vmcore
CPUS: 4
DOMAINS: 5
UPTIME: --:--:--
MACHINE: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2660 Mhz)
MEMORY: 2 GB
----------------

This patch is for crash-4.0-7.2.

Thanks
Itsuro Oda

---
--- defs.h.org 2008-10-09 09:25:11.000000000 +0900
+++ defs.h 2008-10-09 09:53:53.000000000 +0900
@@ -4118,6 +4118,8 @@
int is_sadump_xen(void);
void set_xen_phys_start(char *);
ulong xen_phys_start(void);
+int xen_major_version(void);
+int xen_minor_version(void);

/*
* diskdump.c
--- netdump.h.org 2008-10-09 09:25:03.000000000 +0900
+++ netdump.h 2008-10-09 09:49:26.000000000 +0900
@@ -110,6 +110,8 @@
int p2m_frames;
ulong *p2m_mfn_frame_list;
ulong xen_phys_start;
+ int xen_major_version;
+ int xen_minor_version;
};

#define KDUMP_P2M_INIT (0x1)
--- netdump.c.org 2008-10-09 09:24:54.000000000 +0900
+++ netdump.c 2008-10-09 09:53:20.000000000 +0900
@@ -1525,6 +1525,8 @@
nd->xen_kdump_data->p2m_mfn = *(uptr+(words-1));
if (words > 9 && !nd->xen_kdump_data->xen_phys_start)
nd->xen_kdump_data->xen_phys_start = *(uptr+(words-2));
+ nd->xen_kdump_data->xen_major_version = *uptr;
+ nd->xen_kdump_data->xen_minor_version = *(uptr+1);
}
}
break;
@@ -1730,6 +1732,8 @@
nd->xen_kdump_data->p2m_mfn = *(up+(words-1));
if (words > 9 && !nd->xen_kdump_data->xen_phys_start)
nd->xen_kdump_data->xen_phys_start = *(up+(words-2));
+ nd->xen_kdump_data->xen_major_version = *up;
+ nd->xen_kdump_data->xen_minor_version = *(up+1);
}
}
break;
@@ -2343,3 +2347,15 @@
{
return nd->xen_kdump_data->xen_phys_start;
}
+
+int
+xen_major_version(void)
+{
+ return nd->xen_kdump_data->xen_major_version;
+}
+
+int
+xen_minor_version(void)
+{
+ return nd->xen_kdump_data->xen_minor_version;
+}
--- xen_hyper_defs.h.org 2008-10-06 13:45:39.000000000 +0900
+++ xen_hyper_defs.h 2008-10-06 13:44:44.000000000 +0900
@@ -134,9 +134,8 @@
#endif

#if defined(X86) || defined(X86_64)
-#define XEN_HYPER_PERCPU_SHIFT 12
#define xen_hyper_per_cpu(var, cpu) \
- ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT))
+ ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift))
#elif defined(IA64)
#define xen_hyper_per_cpu(var, cpu) \
((xht->flags & XEN_HYPER_SMP) ? \
@@ -404,6 +403,7 @@
ulong *cpumask;
uint *cpu_idxs;
ulong *__per_cpu_offset;
+ int percpu_shift;
};

struct xen_hyper_dumpinfo_context {
--- xen_hyper.c.org 2008-10-06 13:41:14.000000000 +0900
+++ xen_hyper.c 2008-10-09 11:31:24.000000000 +0900
@@ -71,6 +71,13 @@
#endif

#if defined(X86) || defined(X86_64)
+ if (symbol_exists("__per_cpu_shift")) {
+ xht->percpu_shift = (int)symbol_value("__per_cpu_shift");
+ } else if (xen_major_version() >= 3 && xen_minor_version() >= 3) {
+ xht->percpu_shift = 13;
+ } else {
+ xht->percpu_shift = 12;
+ }
member_offset = MEMBER_OFFSET("cpuinfo_x86", "x86_model_id");
buf = GETBUF(XEN_HYPER_SIZE(cpuinfo_x86));
if (xen_hyper_test_pcpu_id(XEN_HYPER_CRASHING_CPU())) {
@@ -1746,9 +1753,11 @@
tmp2 = (ulong)jiffies_64;
jiffies_64 = (ulonglong)(tmp2 - tmp1);
}
- } else {
+ } else if (symbol_exists("jiffies")) {
get_symbol_data("jiffies", sizeof(long), &jiffies);
jiffies_64 = (ulonglong)jiffies;
+ } else {
+ jiffies_64 = 0; /* hypervisor does not have uptime */
}

return jiffies_64;
--- xen_hyper_command.c.org 2008-10-07 08:05:37.000000000 +0900
+++ xen_hyper_command.c 2008-10-07 08:24:29.000000000 +0900
@@ -1022,7 +1022,8 @@
(buf1, "%d\n", XEN_HYPER_NR_DOMAINS()));
/* !!!Display a date here if it can be found. */
XEN_HYPER_PRI(fp, len, "UPTIME: ", buf1, flag,
- (buf1, "%s\n", convert_time(xen_hyper_get_uptime_hyper(), buf2)));
+ (buf1, "%s\n", (xen_hyper_get_uptime_hyper() ?
+ convert_time(xen_hyper_get_uptime_hyper(), buf2) : "--:--:--")));
/* !!!Display a version here if it can be found. */
XEN_HYPER_PRI_CONST(fp, len, "MACHINE: ", flag);
if (strlen(uts->machine)) {
---
--
Itsuro ODA <oda@valinux.co.jp>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel