From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1hEl-0000TZ-RH for qemu-devel@nongnu.org; Sat, 02 Feb 2013 12:50:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U1hEk-0006Sg-FZ for qemu-devel@nongnu.org; Sat, 02 Feb 2013 12:50:47 -0500 Received: from cantor2.suse.de ([195.135.220.15]:46498 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1hEk-0006Sc-5u for qemu-devel@nongnu.org; Sat, 02 Feb 2013 12:50:46 -0500 Message-ID: <510D51F0.5070800@suse.de> Date: Sat, 02 Feb 2013 18:50:40 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1359823557-5748-1-git-send-email-afaerber@suse.de> <510D4EF6.6030702@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for-1.4] libi2c-omap: Fix endianness dependency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: blauwirbel@gmail.com, dantesu@gmail.com, rth@twiddle.net, agraf@suse.de, qemu-devel@nongnu.org Am 02.02.2013 18:44, schrieb Peter Maydell: > On 2 February 2013 17:37, Andreas F=C3=A4rber wrote: >> Am 02.02.2013 17:49, schrieb Peter Maydell: >>> There's nothing special about the OMAP i2c device that I know of: >>> shouldn't the test code just be using a generic "write 16 bit value >>> to memory with appropriate endianness for target CPU" function ? >> >> I asked about where to address this issue [1], no concrete answers, an= d >> this is the only solution I came up with. >> >> libqtest.h has no generic endian-aware memread functions unlike Alex, >> you or me expected. It reads a sequence of bytes from guest memory and >> transmits them one-by-one over the text-based qtest protocol. >=20 > OK, so this is just busted for accessing devices. The protocol > has to have some way of letting you do a 32 bit / 16 bit / 8 bit > access (and maybe 64 bit as well while we're here). memread > and memwrite are OK for RAM accesses [ie anything you'd be > happy to have cached or buffered in a real system] but for > memory mapped registers we need to have an equivalent of > inb/inw/inl/outb/outw/outl that guarantee to do exactly one > access of exactly the required width. >=20 > (If you want to do a workaround for 1.4 to get the test suite > running again I don't object; this is just a discussion about > what the right long term fix should be.) OK. As discussed with Alex in IRC, I think the issue is that libqtest does not know about which endianness the guest uses, so the only thing we can do on the library side is generalize my helpers (e.g., memread_le16u). Anything else would need to be done in qtest.c, i.e. adding new commands to the protocol (e.g., memread16) and implementing them on both sides. m48t59-test, as only other memread() user, gets around this due to doing byte access only. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg