From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:57508)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UCsgD-0001su-5H
	for qemu-devel@nongnu.org; Tue, 05 Mar 2013 09:17:25 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UCsgB-0007b2-Ak
	for qemu-devel@nongnu.org; Tue, 05 Mar 2013 09:17:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:28954)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UCsgB-0007at-2j
	for qemu-devel@nongnu.org; Tue, 05 Mar 2013 09:17:19 -0500
Message-ID: <5135FE69.4040104@redhat.com>
Date: Tue, 05 Mar 2013 15:17:13 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <cover.1362290776.git.peter.crosthwaite@xilinx.com>
	<11e3c93f4c64bda4ef46ec9de8dd8b4fa88b3ec5.1362290776.git.peter.crosthwaite@xilinx.com>
	<CAAu8pHsH6m8gwg36-gm-d9a4hVLeEK9BGhNyLbdDXnqX9FNuxQ@mail.gmail.com>
	<20130304094414.GA31974@redhat.com>
	<CAAu8pHss-=ud24AV92YaaWF5efCpuWMGPkU5yMw9xbdjiv+iqQ@mail.gmail.com>
	<20130305133401.GD2256@redhat.com>
In-Reply-To: <20130305133401.GD2256@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH v1 2/4] bitops: Add UInt32StateInfo and
 helper functions
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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>, peter.maydell@linaro.org, Peter Crosthwaite <peter.crosthwaite@xilinx.com>, qemu-devel@nongnu.org, Anthony Liguori <aliguori@us.ibm.com>

  Hi,

>>>> We also need uint8_t, uint16_t and uint64_t versions for some devices.
>>>> Perhaps it would be better to implement a uint64_t device which can be
>>>> used with shorter widths or even stronger connection with memory API.
>>>
>>> Why not uint8_t for everyone?
>>
>> That would be simple, but then modeling for example 32 bit registers
>> gets clumsy.
> 
> The way we do this in pci is support wrappers for word/long accesses.
> This is a nice way to do endian-ness conversion anyway, I guess.
> If people are interested, it shouldn't be hard to generalize the pci code...

> At least with PCI, guest can perform a long access and host word access
> to the same register, so width is not a register property.

Thanks, but I'm not interested.

Memory API handles this just fine for me, and there is zero reason to
care about how the guests accesses the registers (unless the hardware
you are emulating behaves strange enough that you have to care to get it
right).

cheers,
  Gerd