From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0yvZ-0001bS-M4 for qemu-devel@nongnu.org; Tue, 16 Dec 2014 15:41:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0yvT-0006wv-CW for qemu-devel@nongnu.org; Tue, 16 Dec 2014 15:41:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0yvT-0006wl-40 for qemu-devel@nongnu.org; Tue, 16 Dec 2014 15:40:59 -0500 Message-ID: <549098D2.5020001@redhat.com> Date: Tue, 16 Dec 2014 21:40:50 +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> In-Reply-To: <549090D8.5010006@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:06, Laszlo Ersek wrote: > On 12/16/14 20:49, Paolo Bonzini wrote: >> fw_cfg_read (and >> thus fw_cfg_data_mem_read) is not idempotent. The split/compose stuff >> accesses the bytes at offsets 8,9,10,11,12,13,14,15 and composes them >> according to the endianness. >> >> In the case of fw_cfg it just retrieves 8 bytes, but in the case of host >> big endian it reads them in the "wrong" order for some reason (sorry, I >> haven't looked at this thoroughly). > > 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. Honestly neither can I. But still the automatic splitting (which is even tested by tests/endianness-test.c :)) assumes idempotency of the components and it's not entirely surprising that it somehow/sometimes breaks if you don't respect that. >> So the solution is: >> >> 1) make fw_cfg_data_mem_ops DEVICE_LITTLE_ENDIAN >> >> 2) make fw_cfg_data_mem_read and fw_cfg_data_mem_write call fw_cfg_read >> and fw_cfg_write SIZE times and build up a value from the lowest byte up. > > Nonetheless, that's a really nice idea! I got so stuck with the > automatic splitting that I forgot about the possibility to act upon the > "size" parameter in fw_cfg_data_mem_read(). Thanks! > > ... Another thing that Andrew mentioned but I didn't cover in my other > email -- what about fw_cfg_ctl_mem_ops? It's currently DEVICE_NATIVE_ENDIAN. > > You flipped the combined ops to LE in commit 6fdf98f2 (and, apparently, > I reviewed it). Shouldn't we do the same for the standalone selector? No. The standalone selector is used as MMIO, and the BE platforms expect the platform to be big-endian. The combined ops are only used on ISA ports, where the firmware expects them to be little-endian (as mentioned in the commit message). That said, the standalone selector is used by BE platforms only, so we know that the standalone selector is always DEVICE_BIG_ENDIAN. So if you want, you can make the standalone selector and the standalone datum BE and swap them in the firmware. If the suggestion doesn't make you jump up and down, I understand that. :) Paolo