From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40559 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PM3Mq-00045M-B4 for qemu-devel@nongnu.org; Fri, 26 Nov 2010 13:49:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PM3Mo-0002Td-PR for qemu-devel@nongnu.org; Fri, 26 Nov 2010 13:49:56 -0500 Received: from cantor.suse.de ([195.135.220.2]:38579 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PM3Mo-0002TJ-Eu for qemu-devel@nongnu.org; Fri, 26 Nov 2010 13:49:54 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: Date: Fri, 26 Nov 2010 19:49:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09AF9F0A-2A29-4D53-8567-2DD60E5DD4D0@suse.de> References: <1290670555-12575-1-git-send-email-agraf@suse.de> Subject: [Qemu-devel] Re: [PATCH 00/15] [RFC] MMIO endianness cleanup List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: QEMU-devel Developers , Paul Brook On 26.11.2010, at 19:44, Blue Swirl wrote: > On Thu, Nov 25, 2010 at 7:35 AM, Alexander Graf wrote: >> The way mmio endianness is currently implemented is horrifying. >>=20 >> In the real world, CPUs have an endianness and write out data >> to the memory bus. Instead of RAM, a receiving side here can be >> a device. This device gets a byte stream again and needs to >> make sense of it. >>=20 >> Since big endian systems write big endian numbers into memory >> while little endian systems write little endian numbers there, >> the device and software on the CPU need to be aware of this. >>=20 >> In practice, most devices these days (ISA, PCI) assume that >> the data is little endian. So to communicate with such a device >> from the CPU's side, the OS byte swaps all MMIO. >>=20 >> In qemu however, we simply pass the register value we find on >> to the device. So any byte mangling the guest does to compensate >> for the transfer screw us up by exposing byte swapped MMIO >> on the device's side. >>=20 >> The way this has been fixed historically is by constructs like >> this one: >>=20 >> #ifdef TARGET_WORDS_BIGENDIAN >> val =3D bswap32(val); >> #endif >>=20 >> With the move to get device code only compiled once, this has >> become harder and harder to justify though, since we don't know >> the target endianness during compile time. >>=20 >> It's especially bad since it doesn't make any sense at all to >> clutter all the device code with endianness workarounds, aside >> from the fact that about 80% of the device code currently does >> the wrong thing :). >>=20 >> So my solution to the issue is to make every device define if >> it's a little, big or native (target) endianness device. This >> basically tells the layers below what endianness the device >> expects mmio to occur in. Little endian devices on little endian >> hosts don't swap. On big endian hosts they do. Same the other >> way around. >>=20 >> The only reason I added "native" endianness is that we have some >> PV devices like the fw_cfg that expect qemu's broken behavior. >> These devices are the minority though. In the long run I'd expect >> to see most code be committed with either of the two endianness >> choices. >>=20 >> The patch set also includes a bunch of conversions for devices >> that were already aware of endianness. >>=20 >> This is an RFC, so please comment as much as you can :). >=20 > Nice approach, better than mine. I'm looking forward to see VGA > converted ;-). It's used by almost all targets, so that conversion > would save a lot of compile cycles. The only issue for VGA should be the frame buffer. Since we can keep = that as DEVICE_NATIVE_ENDIAN, we should be good. I hope. Not sure yet. = :) So far there hasn't really been any negative feedback. Should we take = this RFC as v1 and just merge it? Alex