9:35 a.m.
Hello Itsuro,
I have only briefly scanned your patch, and find it very
interesting. I am not at all familiar with the hypervisor
code, but I do have a couple simple questions at this point:
1. Is it necessary to create a separate "xencrash"
binary? Would it be possible to create a single
crash binary that can be used for both vmlinux
and xen-syms sessions?
Sorry about this -- I missed the following two parts of
the Makefile and main.c patches!
+
+xencrash: crash
+ cp -f crash xencrash
+ if (STREQ(pc->program_name, "xencrash"))
+ pc->flags |= XEN_HYPER;
However, given the above, I wonder whether it would be possible
to postpone the setting of the XEN_HYPER flag from the
setup_environment() function until later on in main() when
the command line arguments are parsed? Wouldn't it be possible
to recognize that the xen-syms object file is the hypervisor
binary, and to set the XEN_HYPER flag at that point?
Thanks,
Dave
2. Can you make it work with a live hypervisor system
in the same way the crash works with a live Linux
kernel?
Thanks,
Dave
7:12 p.m.
New subject: xencrash: crash analisys tool for Xen hypervisor
Hi, Dave
However, given the above, I wonder whether it would be possible
to postpone the setting of the XEN_HYPER flag from the
setup_environment() function until later on in main() when
the command line arguments are parsed? Wouldn't it be possible
to recognize that the xen-syms object file is the hypervisor
binary, and to set the XEN_HYPER flag at that point?
I think it is difficult to decide according to content of the
object. It is available to assume the file name of xen-syms.
For example I attached a new version. (main.c only)
Do you think which is better ?
2. Can you make it work with a live hypervisor system
in the same way the crash works with a live Linux
kernel?
No. There is no method to see hypervisor's memory.
Thanks.
Itsuro Oda
---
On Mon, 30 Oct 2006 10:35:32 -0500
Dave Anderson <anderson(a)redhat.com> wrote:
> > Hello Itsuro,
> >
> > I have only briefly scanned your patch, and find it very
> > interesting. I am not at all familiar with the hypervisor
> > code, but I do have a couple simple questions at this point:
> >
> > 1. Is it necessary to create a separate "xencrash"
> > binary? Would it be possible to create a single
> > crash binary that can be used for both vmlinux
> > and xen-syms sessions?
> >
>
> Sorry about this -- I missed the following two parts of
> the Makefile and main.c patches!
>
> +
> +xencrash: crash
> + cp -f crash xencrash
>
>
> + if (STREQ(pc->program_name, "xencrash"))
> + pc->flags |= XEN_HYPER;
>
However, given the above, I wonder whether it would be possible
to postpone the setting of the XEN_HYPER flag from the
setup_environment() function until later on in main() when
the command line arguments are parsed? Wouldn't it be possible
to recognize that the xen-syms object file is the hypervisor
binary, and to set the XEN_HYPER flag at that point?
>
> Thanks,
> Dave
>
> >
> > 2. Can you make it work with a live hypervisor system
> > in the same way the crash works with a live Linux
> > kernel?
> >
> > Thanks,
> > Dave
> >
--
Itsuro ODA <oda(a)valinux.co.jp>
9:45 a.m.
New subject: xencrash: crash analisys tool for Xen hypervisor
Itsuro ODA wrote:
Hi, Dave
> However, given the above, I wonder whether it would be possible
> to postpone the setting of the XEN_HYPER flag from the
> setup_environment() function until later on in main() when
> the command line arguments are parsed? Wouldn't it be possible
> to recognize that the xen-syms object file is the hypervisor
> binary, and to set the XEN_HYPER flag at that point?
I think it is difficult to decide according to content of the
object. It is available to assume the file name of xen-syms.
For example I attached a new version. (main.c only)
Do you think which is better ?
I'm not sure, but I do prefer the checking the "xen-syms" name
vs. checking "crash" vs. "xencrash". What I want to avoid is
using the "xencrash/crash" string as the differentiator, because
it confuses the fact that -- with respect to crash -- the use
of the term "xen" currently implies a dom0 or domU kernel
session.
One small change I might prefer is that the call to check_xen_hyper()
should be made right after is_elf_file() has successfully accepted
the "xen-syms*" command line argument.
However, what I was thinking was that once you have returned from
symtab_init(), you can then easily distinguish between a vmlinux
and xen-syms file by the existence of per-binary symbol names.
And since the xen-syms and vmlinux versions of machdep_init()
for PRE_SYMTAB are identical, that wouldn't seem to be a
problem, at least for x86.
Another possibility would be, again just after the is_elf_file()
call has returned, to check the ELF header for obvious clues
that the binary is *not* a vmlinux file. Like for example,
on an x86_64, the xen-syms file has this PT_LOAD segment:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0xff100000 0xff100000 0x92658 0x92658 RWE 0x1000
With those VirtAddr and PhysAddr (???) values, there's no
way it could be a vmlinux binary.
But -- perhaps the simplest way is the better way, and your check
for the first 8 bytes in the "xen-syms" namelist name is sufficient
for now.
However, we should also have a "--hyper" command line argument to
force a hypervisor session in case everything else fails.
> 2. Can you make it work with a live hypervisor system
> in the same way the crash works with a live Linux
> kernel?
No. There is no method to see hypervisor's memory.
Ah, OK -- that's too bad. That would be nice...
A couple of other suggestions...
1. I understand that the x86_64 is under development,
but the patch as it is now won't compile because the
call to x86_64_init_hyper() is just hanging out there
in the middle of nowhere.
2. I don't see why it's necessary to bother with the
additional BT_XEN_HYPER_MODE flag? It seems
its usage could be replaced with XEN_HYPER_MODE(),
which you also use in lkcd_x86_trace.c.
But on the whole, the patch looks pretty clean,
and as long as the "binary-file-type-determination" can
be resolved cleanly, it looking pretty good.
Thanks,
Dave
5:44 p.m.
New subject: xencrash: crash analisys tool for Xen hypervisor
Hi Dave,
On Tue, 31 Oct 2006 10:45:59 -0500
Dave Anderson <anderson(a)redhat.com> wrote:
Itsuro ODA wrote:
> Hi, Dave
>
> > However, given the above, I wonder whether it would be possible
> > to postpone the setting of the XEN_HYPER flag from the
> > setup_environment() function until later on in main() when
> > the command line arguments are parsed? Wouldn't it be possible
> > to recognize that the xen-syms object file is the hypervisor
> > binary, and to set the XEN_HYPER flag at that point?
>
> I think it is difficult to decide according to content of the
> object. It is available to assume the file name of xen-syms.
> For example I attached a new version. (main.c only)
> Do you think which is better ?
I'm not sure, but I do prefer the checking the "xen-syms" name
vs. checking "crash" vs. "xencrash". What I want to avoid is
using the "xencrash/crash" string as the differentiator, because
it confuses the fact that -- with respect to crash -- the use
of the term "xen" currently implies a dom0 or domU kernel
session.
I see.
One small change I might prefer is that the call to
check_xen_hyper()
should be made right after is_elf_file() has successfully accepted
the "xen-syms*" command line argument.
However, what I was thinking was that once you have returned from
symtab_init(), you can then easily distinguish between a vmlinux
and xen-syms file by the existence of per-binary symbol names.
And since the xen-syms and vmlinux versions of machdep_init()
for PRE_SYMTAB are identical, that wouldn't seem to be a
problem, at least for x86.
Ok, I will check.
Another possibility would be, again just after the is_elf_file()
call has returned, to check the ELF header for obvious clues
that the binary is *not* a vmlinux file. Like for example,
on an x86_64, the xen-syms file has this PT_LOAD segment:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0xff100000 0xff100000 0x92658 0x92658 RWE 0x1000
With those VirtAddr and PhysAddr (???) values, there's no
way it could be a vmlinux binary.
Hmm, anyway, crash is used by analysts who understand what he do.
I think strict checking is not necessary.
But -- perhaps the simplest way is the better way, and your check
for the first 8 bytes in the "xen-syms" namelist name is sufficient
for now.
Yes.
However, we should also have a "--hyper" command line
argument to
force a hypervisor session in case everything else fails.
>
>
> > 2. Can you make it work with a live hypervisor system
> > in the same way the crash works with a live Linux
> > kernel?
>
> No. There is no method to see hypervisor's memory.
>
Ah, OK -- that's too bad. That would be nice...
A couple of other suggestions...
1. I understand that the x86_64 is under development,
but the patch as it is now won't compile because the
call to x86_64_init_hyper() is just hanging out there
in the middle of nowhere.
Sorry. x86_64.c is broken now. I will fix.
2. I don't see why it's necessary to bother with the
additional BT_XEN_HYPER_MODE flag? It seems
its usage could be replaced with XEN_HYPER_MODE(),
which you also use in lkcd_x86_trace.c.
I want to use XEN_HYPER_MODE() too, but
unfortunatly find_trace() uses local valiable "pc" !!
But on the whole, the patch looks pretty clean,
and as long as the "binary-file-type-determination" can
be resolved cleanly, it looking pretty good.
Thanks,
Dave
Thanks.
--
Itsuro ODA <oda(a)valinux.co.jp>
7:27 a.m.
New subject: xencrash: crash analisys tool for Xen hypervisor
Itsuro ODA wrote:
Hmm, anyway, crash is used by analysts who understand what he do.
I think strict checking is not necessary.
You're right -- I agree -- let's just go with the "xen-syms" check.
> But -- perhaps the simplest way is the better way, and your check
> for the first 8 bytes in the "xen-syms" namelist name is sufficient
> for now.
Yes.
> However, we should also have a "--hyper" command line argument to
> force a hypervisor session in case everything else fails.
But let's add --hyper to "long_options" just in case...
Sorry. x86_64.c is broken now. I will fix.
No problem.
One thing re: x86_64 -- unlike x86, please create your own xen-specific
backtrace function to plug into the machdep->back_trace function pointer.
I'm pretty sure you won't be able to make the current version work
for xen!
> 2. I don't see why it's necessary to bother with the
> additional BT_XEN_HYPER_MODE flag? It seems
> its usage could be replaced with XEN_HYPER_MODE(),
> which you also use in lkcd_x86_trace.c.
>
I want to use XEN_HYPER_MODE() too, but
unfortunatly find_trace() uses local valiable "pc" !!
Ah -- that's right, I remember running into the same thing...
How about doing an #undef XEN_HYPER_MODE in lkcd_x86_trace.h,
and then creating a XEN_HYPER_MODE() function in lkcd_x86_trace.c?
> But on the whole, the patch looks pretty clean,
> and as long as the "binary-file-type-determination" can
> be resolved cleanly, it looking pretty good.
>
> Thanks,
> Dave
>
I will be updating http://people.redhat.com with an updated
version before long, but I will leave 4.0-3.8 around if you
still need it. It can be accessed by:
http://people.redhat.com/anderson/crash-4.0-3.8.tar.gz
Thanks,
Dave
5:20 p.m.
New subject: xencrash: crash analisys tool for Xen hypervisor
Hi Dave,
But let's add --hyper to "long_options" just in case...
OK, I will add.
How about doing an #undef XEN_HYPER_MODE in lkcd_x86_trace.h,
and then creating a XEN_HYPER_MODE() function in lkcd_x86_trace.c?
OK, let me consider.
I will be updating http://people.redhat.com with an updated
version before long, but I will leave 4.0-3.8 around if you
still need it. It can be accessed by:
http://people.redhat.com/anderson/crash-4.0-3.8.tar.gz
OK, thanks.
I will update the base version when you will release new version.
It is easy.
Thanks.
--
Itsuro ODA <oda(a)valinux.co.jp>
5:37 p.m.
New subject: xencrash: crash analisys tool for Xen hypervisor
Hi Dave,
One thing re: x86_64 -- unlike x86, please create your own
xen-specific
backtrace function to plug into the machdep->back_trace function pointer.
I'm pretty sure you won't be able to make the current version work
for xen!
Yes, I'm investigating now. "bt" is more difficult than other command.
Thanks.
--
Itsuro ODA <oda(a)valinux.co.jp>
6939
days inactive
6941
days old
devel@lists.crash-utility.osci.io
6 comments
2 participants
participants (2)
-
Dave Anderson -
Itsuro ODA