Re: [Qemu-ppc] [Qemu-devel] [PATCH v5] target-ppc: ppc64 target's virtio can be either endian

[Greg Kurz]

On Tue, 22 Apr 2014 09:19:48 -0400 (EDT)
Dave Anderson <address@hidden> wrote:
> 
> 
> ----- Original Message -----
> > On Mon, Apr 21, 2014 at 4:48 PM, Greg Kurz <address@hidden> wrote:
> > 
> > > On Mon, 21 Apr 2014 09:56:48 +0200
> > > Alexander Graf <address@hidden> wrote:
> > >
> > > >
> > > >
> > > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao <address@hidden>:
> > > > >
> > > > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <address@hidden>
> > > 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                                     address@hidden
                                                 address@hidden
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.