From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rwe9B-000067-7Q for qemu-devel@nongnu.org; Sun, 12 Feb 2012 13:27:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rwe99-00030g-8t for qemu-devel@nongnu.org; Sun, 12 Feb 2012 13:27:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rwe98-00030c-V8 for qemu-devel@nongnu.org; Sun, 12 Feb 2012 13:27:35 -0500 Date: Sun, 12 Feb 2012 20:27:32 +0200 From: "Michael S. Tsirkin" Message-ID: <20120212182731.GB4199@redhat.com> References: <20120212125202.GA23416@redhat.com> <4F37B853.1010405@redhat.com> <20120212134707.GB27718@redhat.com> <4F37C4C8.5000808@redhat.com> <20120212150658.GC27718@redhat.com> <4F3802D7.5060006@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4F3802D7.5060006@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] docs: memory.txt document the endian field List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, jan.kiszka@siemens.com, rth@twiddle.net, qemu-devel@nongnu.org, blauwirbel@gmail.com, michael@walle.cc, Avi Kivity , david@gibson.dropbear.id.au, areis@redhat.com On Sun, Feb 12, 2012 at 07:20:07PM +0100, Andreas F=E4rber wrote: > Am 12.02.2012 16:06, schrieb Michael S. Tsirkin: > > So I think the following is right? > >=20 > >=20 > > commit 02aa79aac9bec1c8c17d1b7b5405b59b649dfdb9 > > Author: Michael S. Tsirkin > > Date: Wed Feb 8 17:16:35 2012 +0200 > >=20 > > docs: memory.txt document the endian field > > =20 > > This is an attempt to document the endian > > field in memory API. As this is a confusing topic, > > add some examples. > > =20 > > Signed-off-by: Michael S. Tsirkin > >=20 > > diff --git a/docs/memory.txt b/docs/memory.txt > > index 5bbee8e..9132c86 100644 > > --- a/docs/memory.txt > > +++ b/docs/memory.txt > > @@ -170,3 +170,48 @@ various constraints can be supplied to control h= ow these callbacks are called: > > - .old_portio and .old_mmio can be used to ease porting from code u= sing > > cpu_register_io_memory() and register_ioport(). They should not = be used > > in new code. > > +- .endianness; specifies the device endian-ness, which affects > > + the handling of the value parameter passed from guest to write > > + and returned to guest from read callbacks, as follows: > > + void write(void *opaque, target_phys_addr_t addr, > > + uint64_t value, unsigned size) > > + uint64_t read(void *opaque, target_phys_addr_t addr, > > + unsigned size) > > + value is always passed in the natural host format, > > + low size bytes in value are set, the rest are zero padded > > + on input and ignored on output. >=20 > Looks good so far. >=20 > > + Legal values for endian-ness are: > > + DEVICE_NATIVE_ENDIAN - The value is left in the format used by gu= est. > > + Note that although this is typically a fixed format as > > + guest drivers take care of endian conversions, >=20 > > + if host endian-ness does not match the device this will > > + result in "mixed endian" since the data is always > > + stored in low bits of value. >=20 > Why "mixed" endian? The host always uses host endianness, and with > "native" we use the (nominal) endianness of the target. > Note that the endianness of the guest might be different from the > target's if the CPU is bi-endian. >=20 > > + > > + To handle this data, on write, you typically need to first > > + convert to the appropriate type, removing the > > + padding. On read, handle the data in the appropriate > > + type and then convert to uint64_t, padding with leading zeroe= s. >=20 > That applies to all three endiannesses, doesn't it? >=20 > Andreas > > + > > + DEVICE_LITTLE_ENDIAN - The value is assumed to be > > + endian, and is converted to host endian. > > + DEVICE_BIG_ENDIAN - The value is assumed to be > > + big endian, and is converted to host endian. > > + > > + As an example, consider a little endian guest writing a 32 bit > > + value 0x12345678 into an MMIO register, on a big endian host. > > + The value passed to the write callback is documented below: > > + > > + DEVICE_NATIVE_ENDIAN - value =3D 0x0000000087654321 > > + Explanation: write callback will get the high bits > > + in value set to 0, and low bits set to data left > > + as is, that is in little endian format. > > + DEVICE_LITTLE_ENDIAN - value =3D 0x0000000012345678 > > + Explanation: the write callback will get the high bits > > + in value set to 0, and low bits set to data in big endian > > + format. > > + DEVICE_BIG_ENDIAN - value =3D 0x0000000087654321 > > + Explanation: the write callback will get the high bits > > + in value set to 0, and low bits set to data in little endian > > + format. > > + >=20 It looks like the text is wrong anyway. I give up for now, maybe Avi can document it properly. > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg