Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes

[Peter Maydell]

On 17 June 2014 12:53, Benjamin Herrenschmidt <address@hidden> wrote:
> On Tue, 2014-06-17 at 13:40 +0200, Greg Kurz wrote:
>> This conclusion was reached while discussing dump support where we
>> use LPCR_ILE, and I wanted to add a common helper to be used by
>> virtio. Please find the thread in the link below:
>>
>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg00415.html
>>
>> Can you elaborate on the "less sense" opinion please ?
>
> I can't fathom how the endianness of a specific CPU at the point of the
> reset makes any sense vs. the overall endianness of the system.
>
> But this is all very theorical, fact is they will always match on
> powerpc, so I don't care that much :)

Well, the point is that "overall endianness of the system"
is hopelessly ill-defined. Does it mean "the endianness that
the CPU is currently configured for" (bad idea if you allow
guest userspace to be LE while guest kernel is BE), "the endianness
that the CPU is currently configured to take exceptions in"
(probably more likely to be the guest kernel endianness, but
when do you sample this value, and what do you do on architectures
where there's no such concept?), or "the endianness of the
external-to-the-CPU bus" (solidly defined but probably not
what you wanted since that means ppcle would still be defined
as 'big-endian')?

What we ended up with was deciding that the only point you
could reasonably sample the CPU state to figure out what
endianness the guest was actually in would be the point
where it actually first touched the virtio device, ie when
it resets it by prodding the relevant registers. That gets
you compatibility with existing guest kernels and avoids
weird issues if you have a BE bootloader that starts a
LE kernel or vice-versa.

As you say, having a register on the device to let the guest
explicitly set the endianness it wants is much nicer and
avoids weird backdoor "look at the CPU state" behaviour.
Unfortunately we're stuck with supporting the existing
virtio kernel drivers.

thanks
-- PMM