From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35964 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONt23-0003Dg-0G for qemu-devel@nongnu.org; Sun, 13 Jun 2010 15:39:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONt21-0005ZV-Nf for qemu-devel@nongnu.org; Sun, 13 Jun 2010 15:39:46 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:48603) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONt21-0005Yy-Fi for qemu-devel@nongnu.org; Sun, 13 Jun 2010 15:39:45 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs Date: Sun, 13 Jun 2010 20:38:35 +0100 References: <201006131939.08385.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006132038.35717.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jan Kiszka , Jan Kiszka , qemu-devel@nongnu.org, Gleb Natapov , Juan Quintela > >> For the memory access case, in practice the interface could be > >> sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr, > >> target_phys_addr_t size) > > > > Why "parent"? > > Parent device or bus host bridge device. Alternatively there could be > a bus handle. A device has no way of knowing where that bust host bridge is, and this may be the wrong device anyway. The access may be directed at another device on the same bus. A bus handle is trivial to derive this from the device itself. > > I don't see any point point trying to squeeze this through a common > > message passing API. We *could* do that if we really wanted, but It's a > > lot of hassle. If devices are going to end up using wrappers that look a > > lot like a straight API then what's the point? > > Without IRQ and other messages, I agree that at this point it would > not make much sense. Do you think this API as straight implementation > would work? Compared to previous attempts for Generic DMA, we'd avoid > any IO vector splitting/reallocations etc. We have already merged a "generic DMA" infrastructure (cpu_physical_memory_map). See also dma-helpers.c for code that uses this to implement zero-copy transfers to/from block devices. This is missing code to allow manipulation by intermediate bus/bridges, but I believe the basic API is fairly sound. Addition of a device handle or error reporting should be possible without requiring major changes to the device code. Paul