From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45841 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONX8L-0002mG-1J for qemu-devel@nongnu.org; Sat, 12 Jun 2010 16:16:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONX8K-0001l2-2j for qemu-devel@nongnu.org; Sat, 12 Jun 2010 16:16:49 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:56940) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONX8J-0001ka-QS for qemu-devel@nongnu.org; Sat, 12 Jun 2010 16:16:48 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs Date: Sat, 12 Jun 2010 21:15:37 +0100 References: <201006121658.58928.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006122115.38581.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 > > [*] A simple unidirectional dma request line is suitable for qmu_irq. A > > DMA system that transfers data outside of memory read/write transactions > > is not. e.g. ISA effectively defines a regular memory bus plus 8 > > bidirectional data streams (aka DMA channels). These are multiplexed > > over the same physical pins, but logically distinct. The DMA channels > > could either be bundled up into the ISA bus interface, or modelled as > > links between devices and the DMA controller. > > Very very interesting. There's some out of band data related to DMA > (bus errors, IOMMU faults, ISA DREQ) which hasn't been covered in > previous Generic DMA proposals. I suspect you're confusing two different concepts - bus-master DMA (memory accesses generated by devices) v.s. IO channel DMA (out of band data stream between a device and a third party DMA engine). Despite both being called "DMA", they significantly different beasts. The IO channel DMA master is effectively a bridge between the memory bus (accessed via bus-master DMA) and the device IO channel. Note that actual IO channel DMA is relatively rare. While many embedded devices still have a DMA engine this tends to generate regular memory accesses, which are then programmed to access a memory mapped FIFO. This shouldn't need any special magic to implement, typically just a simple qemu_irq control line. > Maybe all we need is a generic side > band link, which would be usable for point to point (qemu_irq, > coalescing, messages) and bus channels? We may want to consider a common mechanism for mapping links between devices. i.e some way of saying "Connect device X port N to device Y port M". In the case of traditional interrupts each IRQ source or sink would be a "port". For a bus system you'd probably want to connect them all to a [virtual] bus arbiter object. This should allow the mapping core to verify that e.g. you're not connecting a qemu_irq to something expecting an apic_message, preferably without knowing or caring how either of those work. In theory I guess you could also use the same mechanism to connect network devices to their host interface, etc. I haven't thought this bit through fully, so this may be excessively clever. Paul