On 17 June 2014 12:53, Benjamin Herrenschmidt <b...@kernel.crashing.org> 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