Re: [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and config access

[Anthony Liguori]

Peter Maydell <address@hidden> writes:

> On 8 August 2013 16:40, Anthony Liguori <address@hidden> 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