From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6JCl-0001Zo-Ej for qemu-devel@nongnu.org; Wed, 31 Dec 2014 08:20:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y6JCh-0003v7-Dq for qemu-devel@nongnu.org; Wed, 31 Dec 2014 08:20:51 -0500 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:39587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6JCh-0003uy-7s for qemu-devel@nongnu.org; Wed, 31 Dec 2014 08:20:47 -0500 Received: by mail-wi0-f180.google.com with SMTP id n3so25510226wiv.13 for ; Wed, 31 Dec 2014 05:20:46 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54A3F829.4000509@redhat.com> Date: Wed, 31 Dec 2014 14:20:41 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1420024880-15416-1-git-send-email-lersek@redhat.com> In-Reply-To: <1420024880-15416-1-git-send-email-lersek@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , Peter Maydell , Alexander Graf , Drew Jones , Gerd Hoffmann , qemu devel list On 31/12/2014 12:21, Laszlo Ersek wrote: > Because register emulation in QEMU is integer-preserving, not > string-preserving (see (2)), we have to jump through a few hoops. > > (3a) We defined the memory mapped fw_cfg data register as > DEVICE_BIG_ENDIAN. > > The particular choice is not really relevant -- we picked BE only for > consistency with the control register, which *does* transfer integers -- > but our choice affects how we must host-encode values from fw_cfg strings. > > (3b) Since we want the fw_cfg string "XY" to appear as the [0x58, 0x59] > array on the data register, *and* we picked DEVICE_BIG_ENDIAN, we must > compose the host (== C language) value 0x5859 in the read accessor > function. I'm not sure this is right. DEVICE_BIG_ENDIAN means that if we return 0xaabb and the guest is little endian, it will return 0xbbaa. But the value returned by the accessor is always in host endianness. And it makes sense to swap in the guest if the register is big endian but the guest is little endian. So IMHO your old code is right. Either you are overthinking it, or I'm underthinking it... Knowing our respective personalities, either possibility is just as likely... ;) Paolo