qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dave Anderson
Subject: Re: [Qemu-devel] [PATCH v5] target-ppc: ppc64 target's virtio can be either endian
Date: Tue, 22 Apr 2014 11:57:33 -0400 (EDT)


----- Original Message -----
> 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 ?

Pretty much, yes...

Dave

> 
> > > 
> > > 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.
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]