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 09:19:48 -0400 (EDT)


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

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



reply via email to

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