From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjBdE-0008HM-Nj for qemu-devel@nongnu.org; Tue, 19 Jul 2011 10:50:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjBdC-0008Ml-Ue for qemu-devel@nongnu.org; Tue, 19 Jul 2011 10:50:44 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:64464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjBdC-0008MT-E4 for qemu-devel@nongnu.org; Tue, 19 Jul 2011 10:50:42 -0400 Received: by pzk3 with SMTP id 3so5048563pzk.5 for ; Tue, 19 Jul 2011 07:50:40 -0700 (PDT) Message-ID: <4E2599BC.9070407@codemonkey.ws> Date: Tue, 19 Jul 2011 09:50:36 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1310901265-32051-1-git-send-email-avi@redhat.com> <4E2581F4.5090004@codemonkey.ws> <4E25864A.10905@redhat.com> In-Reply-To: <4E25864A.10905@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/19/2011 08:27 AM, Avi Kivity wrote: > On 07/19/2011 04:09 PM, Anthony Liguori wrote: >> On 07/17/2011 06:13 AM, Avi Kivity wrote: >>> New in this version: >>> MemoryRegionOps gained .old_mmio and .old_portio members, which allow >>> reusing old-style callbacks with the new API. All uses were converted, >>> except for eepro100.c, which uses the same MemoryRegionOps for both >>> portio and mmio. Some intermediate patches do introduce dispatching >>> callbacks, but they are removed later. >>> >>> Caveats: >>> - some devices still grab a global memory region instead of inheriting >>> it from their bus. Seen in the code as #include "exec-memory.h" >> >> Could you write up a quick document on how to use this new api for docs/? > > Sure. It's pretty simple. Thanks. >> >> There's bits I don't like about the interface > > Which bits are these? Nothing I haven't already commented on. I think there's too much in the generic level. I don't think coalesced I/O belongs here. It's a concept that doesn't fit. I think a side-band API would be nicer. Endianness also seems out of place. There are many layers that can affect final endianness. It depends on how devices handle endianness and also whether the bus modifies endianness. There are numerous devices that have a register that allows endianness to be toggled for the device. That makes the actual endianness of the device dynamic which doesn't fit the memory region API very well IMHO. > >> but I think it's a huge improvement over what we have now so I'm >> inclined to commit once it includes documentation. >> > > My problem is that to start leveraging it, everything must flow through > it. There are still several hundred call sites that are unconverted. Really several hundred? That surprises me. Regards, Anthony Liguori > > One option is to invert the relationship between ram_addr_t and > MemoryRegion - implement the former in terms of the latter. That only > works for uses which don't invoke IO_MEM_UNASSIGNED or address arithmetic. >