> > [*] 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