On Tue, 22 Apr 2014 09:19:48 -0400 (EDT)
Dave Anderson <ander...@redhat.com> wrote:
>
>
> ----- Original Message -----
> > On Mon, Apr 21, 2014 at 4:48 PM, Greg Kurz <gk...@linux.vnet.ibm.com> wrote:
> >
> > > On Mon, 21 Apr 2014 09:56:48 +0200
> > > Alexander Graf <ag...@suse.de> wrote:
> > >
> > > >
> > > >
> > > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata....@gmail.com>:
> > > > >
> > > > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gk...@linux.vnet.ibm.com>
> > > wrote:
> > > > >>
> > > > >> +
> > > > >> +#if !defined(CONFIG_USER_ONLY)
> > > > >> +bool virtio_is_big_endian(void)
> > > > >> +{
> > > > >> + PowerPCCPU *cp = POWERPC_CPU(first_cpu);
> > > > >> + CPUPPCState *env = &cp->env;
> > > > >> +
> > > > >> + /* NOTE: booke uses the same number for another unrelated spr.
> > > > >> + */
> > > > >> + if (strcmp(env->spr_cb[SPR_LPCR].name, "LPCR")) {
> > > > >> + return TARGET_WORDS_BIGENDIAN;
> > > > >> + } else {
> > > > >> + return !(env->spr[SPR_LPCR] & LPCR_ILE);
> > > > >> + }
> > > > >> +}
> > > > >> +#endif
> > > > >
> > > > > I am adding crash support for little endian ppc64 guests and I
> > > realized that the above code needs to be re-used in
> > > target-ppc/arch_dump.c:cpu_get_dump_info() to set the endianness.
> > > >
> > > > Wouldn't it make more sense to treat dumps like gdb and set the
> > > endianness depending on MSR_LE?
> > > >
> > > > Alex
> > > >
> > >
> > > It makes sense to behave the same as gdb... and BTW, since the guest may
> > > change endianness, we could possibly have MSB and LSB data in the dump.
> > > The
> > > important thing is to have the possibility to adapt endianness to what we
> > > are
> > > looking (like set target endian in gdb).
> > >
> >
> > Typically guest system dump generated by QEMU (via dump-system-memory
> > monitor cmd) is analysed using the crash utility
> > (http://people.redhat.com/anderson/).
> > Crash tool is a wrapper around gdb and in addition to normal gdb commands,
> > it supports various other commands which make sense for a system dump.
> >
> > Based on my limited exposure to crash tool, currently crash tool doesn't
> > support dynamic setting of endianness (like gdb's set endian command) and
> > it just goes by the endianness recorded in the ELF header and fails if
> > there is any endian mismatch b/n the dump file and the guest vmlinux file.
> > I thought that this is an expected or acceptable behaviour when analyzing
> > system dumps and not sure if a system dump analyzing tool should adapt to
> > endianness when analyzing system dumps. Copying Dave Anderson (of crash
> > utility) for his views here.
>
> Actually the crash utility doesn't compare the dumpfile to the vmlinux file,
> but rather it will not initialize if the endianness of the vmlinux file or of
> an ELF vmcore dumpfile does not match the __BYTE_ORDER compiled into the crash
> binary itself.
>
> Dave
>
So if we want to debug PPC64 LE and PPC64 BE, we need two different crash
binaries. And it is the user call to choose the appropriate one, correct ?
> >
> > To answer Alex's earlier question about what do we want to analyze when we
> > take a system dump of a big endian powerpc VM while it was running lx86
> > program, I would think that since this is system dump, we will want to
> > analyze the system as a whole and hence would need to consider the system
> > endianness reflected by LPCR_ILE rather than current endianess reflected by
> > MSR_LE.
> >
> > Regards,
> > Bharata.
> >
>
--
Gregory Kurz kurzg...@fr.ibm.com
gk...@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys http://www.ibm.com
Tel +33 (0)562 165 496
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
