From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zyS-0003sq-1Q for qemu-devel@nongnu.org; Tue, 16 Dec 2014 16:48:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0zyJ-0007ij-0L for qemu-devel@nongnu.org; Tue, 16 Dec 2014 16:48:07 -0500 Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:43180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zyI-0007if-Mv for qemu-devel@nongnu.org; Tue, 16 Dec 2014 16:47:58 -0500 Received: by mail-wi0-f177.google.com with SMTP id l15so14053757wiw.4 for ; Tue, 16 Dec 2014 13:47:58 -0800 (PST) Sender: Paolo Bonzini Message-ID: <5490A88A.4030003@redhat.com> Date: Tue, 16 Dec 2014 22:47:54 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1418399932-7658-1-git-send-email-lersek@redhat.com> <1418399932-7658-2-git-send-email-lersek@redhat.com> <20141216134858.GD3283@hawk.usersys.redhat.com> <5490815E.8@redhat.com> <54908CB6.8030501@redhat.com> <549090D8.5010006@redhat.com> <54909348.6060507@redhat.com> In-Reply-To: <54909348.6060507@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v4 1/8] fw_cfg: max access size and region size are the same for MMIO data reg List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , Andrew Jones Cc: peter.maydell@linaro.org, Alexander Graf , qemu-devel@nongnu.org On 16/12/2014 21:17, Laszlo Ersek wrote: >> > I can't imagine how that would happen; fw_cfg_data_mem_read() ignores >> > both "addr" and "size", and fw_cfg_read() simply advances the >> > "cur_offset" member. > Ah okay, I understand your point now; you're probably saying that > access_with_adjusted_size() traverses the offsets in the wrong order. > ... I don't see how; the only difference in the access() param list is > the shift count. (I don't know how it should work by design.) I think I have figured it out. Guest endianness affects where those bytes are placed, but not the order in which they are fetched; and the effects of guest endianness are always cleaned up by adjust_endianness, so ultimately they do not matter. Think of how you would implement the uint64_t read in fw_cfg: File bytes 12 34 56 78 9a bc de f0 fw_cfg_data_mem_read should read size==4 BE host 0x12345678 size==4 LE host 0x78563412 size==8 BE host 0x123456789abcdef0 size==8 LE host 0xf0debc9a78563412 So the implementation of fw_cfg_data_mem_read must depend on host endianness. Instead, memory.c always fills in bytes in the same order, on the assumption that the reads are idempotent. Paolo