> Am 21.04.2014 um 10:55 schrieb Bharata B Rao <bharata....@gmail.com>:
>
>> On Mon, Apr 21, 2014 at 1:26 PM, 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?
>
> 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
