On Mon, 2013-08-12 at 09:58 +0930, Rusty Russell wrote: > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > > 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. > > Which is why my original patches nabbed the endianness when the target > updated the virtio device status. > > You're making an assumption about the nature of the guest, that they > don't pass the virtio device directly through to userspace.
Two points here: - Userspace is VERY likely to have the same endianness as the operating system. - The case where we might support "foreign endian" userspace *and* pass virtio directly to it *and* give a shit about virtio v1.0 doesn't exist anywhere but your imagination right now :-) > I don't care, though. The point is to make something which works, until > the Real Fix (LE virtio). Exactly. > > 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. > > OK. What should Anton's gdb stub do then? Something else. It's a different problem and needs a different solution. For one, I think, we should first fix the root problem with gdb (tagging endianness in the protocol etc...) and once that's done, look at what band-aid can be applied for old stuff if we care at all (it's not like LE ppc64 is going to not require a new gdb anyway). Cheers, Ben.