From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8gK3-0000Y7-5c for qemu-devel@nongnu.org; Sun, 11 Aug 2013 20:49:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V8gJy-0003Gm-8w for qemu-devel@nongnu.org; Sun, 11 Aug 2013 20:49:23 -0400 Received: from gate.crashing.org ([63.228.1.57]:55565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8gJx-0003GW-Vt for qemu-devel@nongnu.org; Sun, 11 Aug 2013 20:49:18 -0400 Message-ID: <1376268545.32100.147.camel@pasglop> From: Benjamin Herrenschmidt Date: Mon, 12 Aug 2013 10:49:05 +1000 In-Reply-To: <8761vboiqu.fsf@rustcorp.com.au> References: <1375938949-22622-1-git-send-email-rusty@rustcorp.com.au> <1375938949-22622-2-git-send-email-rusty@rustcorp.com.au> <87li4cgvh1.fsf@codemonkey.ws> <5203AB19.9070505@suse.de> <87r4e4p4wj.fsf@codemonkey.ws> <5203C62C.2040303@suse.de> <87eha3nwoa.fsf@rustcorp.com.au> <1376034579.32100.23.camel@pasglop> <8761vboiqu.fsf@rustcorp.com.au> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and config access List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: Peter Maydell , anton@samba.org, Andreas =?ISO-8859-1?Q?F=E4rber?= , Anthony Liguori , qemu-devel@nongnu.org On Mon, 2013-08-12 at 09:58 +0930, Rusty Russell wrote: > Benjamin Herrenschmidt 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.