qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.4] libi2c-omap: Fix endianness dependency


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH for-1.4] libi2c-omap: Fix endianness dependency
Date: Sat, 02 Feb 2013 18:50:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Am 02.02.2013 18:44, schrieb Peter Maydell:
> On 2 February 2013 17:37, Andreas Färber <address@hidden> 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, and
>> 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.
> 
> 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.
> 
> (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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]