From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58379)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1Y0yYg-0003kC-Iz
	for qemu-devel@nongnu.org; Tue, 16 Dec 2014 15:17:32 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1Y0yYa-0004co-Ff
	for qemu-devel@nongnu.org; Tue, 16 Dec 2014 15:17:26 -0500
Received: from mx1.redhat.com ([209.132.183.28]:51537)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1Y0yYa-0004cf-6p
	for qemu-devel@nongnu.org; Tue, 16 Dec 2014 15:17:20 -0500
Message-ID: <54909348.6060507@redhat.com>
Date: Tue, 16 Dec 2014 21:17:12 +0100
From: Laszlo Ersek <lersek@redhat.com>
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: 7bit
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, Andrew Jones <drjones@redhat.com>
Cc: peter.maydell@linaro.org, Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org

On 12/16/14 21:06, Laszlo Ersek wrote:
> On 12/16/14 20:49, Paolo Bonzini wrote:
>>
>>
>> On 16/12/2014 20:00, Laszlo Ersek wrote:
>>> Yes.
>>>
>>> The root of this question is what each of
>>>
>>> enum device_endian {
>>>     DEVICE_NATIVE_ENDIAN,
>>>     DEVICE_BIG_ENDIAN,
>>>     DEVICE_LITTLE_ENDIAN,
>>> };
>>
>> Actually, I think the root of the answer :) is that 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.

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.)

In any case fw_cfg should be able to handle the larger accesses itself.

Thanks
Laszlo