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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2013-08-09 at 17:05 +0930, Rusty Russell wrote:

> > Exactly, just read it as "is in ... Endian mode". On the CPUs I am more
> > familiar with (e.g., 970), this used to be controlled via an MSR bit,

970 didn't have an LE mode :-)

> > which as CPUPPCState::msr exists per CPUState. I did not check on real
> > hardware, but from the QEMU code this would allow for the mixed-endian
> > scenario described above.

This whole exercise should have nothing to do with the current endian
mode of the CPU. If for example you are running lx86 (the x86 emulator
IBM provides) which exploits MSR:LE on POWER7 to run x86 binaries in
userspace, you don't want virtio to suddenly change endian !

The information we care about is the endianness of the operating system.

The most logical way to infer it is a different bit, which used to be
MSR:ILE and is now in LPCR for guests and controlled via a hypercall on
pseries, which indicates what is the endianness of interrupt vectors.

IE. It indicates how the cpu should set MSR:LE when taking an interrupt,
regardless of what the current MSR:LE value is at any given point in
time.

So what should be done in fact is whenever *that* bit is changed
(currently via hcall, maybe via MSR:ILE if we emulate that on older
models or LPCR when we emulate that), then the qemu cpu model can "call
out" to change the "OS endianness" which we can propagate to virtio.

Anything trying to do stuff based on the "current" endianness in the MSR
sounds like a cesspit to me.

> (The next logical step would be for st* and ld* to take the cpu to query
> its endianness, Anthony's weird ideas notwithstanding).

Why would we even consider something like that ?

Ben.