Peter Maydell <peter.mayd...@linaro.org> writes: > On 8 August 2013 16:40, Anthony Liguori <anth...@codemonkey.ws> wrote: >> PPC64 is big endian. AFAIK, there is no such thing as a little endian >> PPC64 processor. > > What's your definition of "little endian processor" here if > it isn't "one which is doing byte swaps of data"? I would > describe a PPC64 with the relevant mode bit set as "little > endian".
Let's focus this to QEMU. PPC64 is still TARGET_WORDS_BIGENDIAN. It would be totally wrong to make this change to either a function call or to TARGET_WORDS_LITTLEENDIAN. >> This is just a processor mode where loads/stores are byte lane swapped. >> Hence the name 'cpu_get_byteswap'. It's just asking whether the >> load/stores are being swapped or not. >> >> At least for PPC64, it's not possible to enable/disable byte lane >> swapping for individual CPUs. It's done through a system-wide hcall. >> >> FWIW, I think most bi-endian architectures are this way too so I think >> this is equally applicable to ARM. Peter, is that right? > > ARM's bi-endian story is complicated and depends on the CPU. > Older CPUs didn't do byte-lane swapping of data; instead > when the CPU was configured in "big endian" mode they would > do address munging (XOR the address with 3 when doing a byte > access; XOR with 1 for halfword access). New CPUs do byte-lane > swapping (but only for data, not for instruction fetch). > CPUs in the transition period can do either. > > In all cases, this is a per-cpu-core thing: you can have > one core configured to be bigendian and the other little > endian. You could in theory have the OS support both big > and little endian userspace processes. We ideally would > want to support "QEMU is a little endian process but the > VM's vcpu is currently bigendian". Eek. Yeah, I guess we need to tie this to a CPUState then. > > Fuller writeup here: > http://translatedcode.wordpress.com/2012/04/02/this-end-up/ Excellent, thanks! Regards, Anthony Liguori > > -- PMM
