From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCsz0-0001tI-SR for qemu-devel@nongnu.org; Tue, 05 Mar 2013 09:36:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCsv0-0004MY-4D for qemu-devel@nongnu.org; Tue, 05 Mar 2013 09:32:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCsuz-0004MN-Nx for qemu-devel@nongnu.org; Tue, 05 Mar 2013 09:32:37 -0500 Date: Tue, 5 Mar 2013 16:32:52 +0200 From: "Michael S. Tsirkin" Message-ID: <20130305143252.GF2256@redhat.com> References: <11e3c93f4c64bda4ef46ec9de8dd8b4fa88b3ec5.1362290776.git.peter.crosthwaite@xilinx.com> <20130304094414.GA31974@redhat.com> <20130305133401.GD2256@redhat.com> <5135FE69.4040104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5135FE69.4040104@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v1 2/4] bitops: Add UInt32StateInfo and helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Blue Swirl , peter.maydell@linaro.org, Peter Crosthwaite , qemu-devel@nongnu.org, Anthony Liguori On Tue, Mar 05, 2013 at 03:17:13PM +0100, Gerd Hoffmann wrote: > 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 If the intended audience uses the memory API, then it's not needed. pci config is not going through a memory API ATM though I think it might be possible to make it do this by creating a separate config address space per device. -- MST