| Message ID | 20140414121020.5987.68525.stgit@bahia.local |
|---|---|
| State | New |
| Headers | show |
On 14.04.14 14:12, Greg Kurz wrote: > We turn the virtio_is_big_endian() helper into a target dependant hook > to compute endianness for legacy virtio devices. > > We base it on the OS endian, as reflected by the endianness of the > interrupt vectors (handled through the ILE bit in the LPCR register). > > Using first_cpu to fetch the registers from KVM may look arbitrary > and awkward, but it is okay because KVM sets/unsets the ILE bit on > all CPUs. > > Note that Book3e has no LPCR and worse, has a unrelated spr at the same > index... I did not find better than strcmp() to ensure we are using > the correct register. > > Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > [ re-use the existing virito_is_big_endian() helper, > check we have LPCR, > Greg Kurz <gkurz@linux.vnet.ibm.com> ] > Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> > Reviewed-by: Alexander Graf <agraf@suse.de> Works for me :). Alex
On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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. Do you think it is worth to have this routine as a generic routine to determine endianness so that subsystems other than virtio can reuse the same ? Regards, Bharata. <http://raobharata.wordpress.com/>
> Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata.rao@gmail.com>: > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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 > > Do you think it is worth to have this routine as a generic routine to determine endianness so that subsystems other than virtio can reuse the same ? > > Regards, > Bharata.
On Mon, Apr 21, 2014 at 1:26 PM, Alexander Graf <agraf@suse.de> wrote: > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata.rao@gmail.com>: > > On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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? > Since we are talking about guest system dumps here and going by what Ben says here (http://article.gmane.org/gmane.comp.emulators.qemu/227201), it appears that using LPCR_ILE would be appropriate. Regards, Bharata.
On Mon, 21 Apr 2014 09:46:59 +0530 Bharata B Rao <bharata.rao@gmail.com> wrote: > On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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. > > Do you think it is worth to have this routine as a generic routine to > determine endianness so that subsystems other than virtio can reuse the > same ? > Hi Bharata, I had comments on this patch that I have addressed, I shall send an update shortly (function will be a CPU object method and, most important, we will rely on current_cpu). So I guess you should not use the code above. > Regards, > Bharata. > <http://raobharata.wordpress.com/> Regards.
> Am 21.04.2014 um 10:55 schrieb Bharata B Rao <bharata.rao@gmail.com>: > >> On Mon, Apr 21, 2014 at 1:26 PM, Alexander Graf <agraf@suse.de> wrote: >> >> >>> Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata.rao@gmail.com>: >>> >> >>>> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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? > > Since we are talking about guest system dumps here and going by what Ben says here (http://article.gmane.org/gmane.comp.emulators.qemu/227201), it appears that using LPCR_ILE would be appropriate. Take the example that Ben raised - lx86 on be. When you create a dump, do you want to analyze lx86 or Linux beneath? For virtio the answer is easy. For crash dumps not so much. I think the most sensible thing to do is to base on msr_le and allow the user to override our clever decision. If you feel strongly for the ILE approach, I won't refuse that either though. That said, in case you do want to go with the ILE approach, make sure you don't call the *virtio specific* cpu callback and that you stay compatible with non-ibm cpus. Alex
On Mon, 21 Apr 2014 09:56:48 +0200 Alexander Graf <agraf@suse.de> wrote: > > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata.rao@gmail.com>: > > > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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). > > > > Do you think it is worth to have this routine as a generic routine to determine endianness so that subsystems other than virtio can reuse the same ? > > > > Regards, > > Bharata.
On Mon, Apr 21, 2014 at 4:48 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: > On Mon, 21 Apr 2014 09:56:48 +0200 > Alexander Graf <agraf@suse.de> wrote: > > > > > > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata.rao@gmail.com>: > > > > > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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. 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.
----- Original Message ----- > On Mon, Apr 21, 2014 at 4:48 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: > > > On Mon, 21 Apr 2014 09:56:48 +0200 > > Alexander Graf <agraf@suse.de> wrote: > > > > > > > > > > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata.rao@gmail.com>: > > > > > > > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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 > > 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. >
On Tue, 22 Apr 2014 09:19:48 -0400 (EDT) Dave Anderson <anderson@redhat.com> wrote: > > > ----- Original Message ----- > > On Mon, Apr 21, 2014 at 4:48 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote: > > > > > On Mon, 21 Apr 2014 09:56:48 +0200 > > > Alexander Graf <agraf@suse.de> wrote: > > > > > > > > > > > > > > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao <bharata.rao@gmail.com>: > > > > > > > > > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz <gkurz@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. > > >
----- Original Message ----- > On Tue, 22 Apr 2014 09:19:48 -0400 (EDT) > Dave Anderson <anderson@redhat.com> wrote: > > > > > > ----- Original Message ----- > > > On Mon, Apr 21, 2014 at 4:48 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> > > > wrote: > > > > > > > On Mon, 21 Apr 2014 09:56:48 +0200 > > > > Alexander Graf <agraf@suse.de> wrote: > > > > > > > > > > > > > > > > > > > > Am 21.04.2014 um 06:16 schrieb Bharata B Rao > > > > > > <bharata.rao@gmail.com>: > > > > > > > > > > > >> On Mon, Apr 14, 2014 at 5:42 PM, Greg Kurz > > > > > >> <gkurz@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 ? 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 kurzgreg@fr.ibm.com > gkurz@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. > >
diff --git a/exec.c b/exec.c index e6777d0..cf98d42 100644 --- a/exec.c +++ b/exec.c @@ -2740,7 +2740,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, } #endif -#if !defined(CONFIG_USER_ONLY) +#if !defined(CONFIG_USER_ONLY) && !defined(TARGET_PPC) /* * A helper function for the _utterly broken_ virtio device model to find out if diff --git a/target-ppc/misc_helper.c b/target-ppc/misc_helper.c index 2eb2fa6..971cafe 100644 --- a/target-ppc/misc_helper.c +++ b/target-ppc/misc_helper.c @@ -20,6 +20,8 @@ #include "helper.h" #include "helper_regs.h" +#include "hw/virtio/virtio.h" +#include "sysemu/kvm.h" /*****************************************************************************/ /* SPR accesses */ @@ -120,3 +122,19 @@ void ppc_store_msr(CPUPPCState *env, target_ulong value) { hreg_store_msr(env, value, 0); } + +#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