From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rmq3N-00036G-Ik for qemu-devel@nongnu.org; Mon, 16 Jan 2012 12:09:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rmq3G-0007m4-Q4 for qemu-devel@nongnu.org; Mon, 16 Jan 2012 12:09:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rmq3G-0007ly-ET for qemu-devel@nongnu.org; Mon, 16 Jan 2012 12:08:58 -0500 Message-ID: <4F1459A4.2030502@redhat.com> Date: Mon, 16 Jan 2012 19:08:52 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1326479558-3016-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/6] qtest: add test framework List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org, Stefan Hajnoczi On 01/16/2012 06:59 PM, Stefan Hajnoczi wrote: > > + } > > + qtest_send_prefix(chr); > > + qtest_send(chr, "OK 0x%04x\n", value); > > Endianness is a little weird here. memory.c will byteswap if target > and device endianness differ. > > Imagine the case where we're on an x86 host, running a ppc guest, > reading from PCI configuration space (little-endian). Since ppc > (target endian) is big-endian and the device is little-endian the > value read/written will be byteswapped. However, our qtest runs on > the host and therefore we don't want that automatic swap (or we need > to neutralize it by performing another byteswap on top). > Good catch. This is another example of how an access depends not only on the destination, but also on the source. Here the source is not the cpu; it's qtest. -- error compiling committee.c: too many arguments to function