From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONT7w-00050D-Ji for qemu-devel@nongnu.org; Sat, 12 Jun 2010 12:00:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONT7u-0000ak-K3 for qemu-devel@nongnu.org; Sat, 12 Jun 2010 12:00:07 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:39817) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONT7u-0000aS-DW for qemu-devel@nongnu.org; Sat, 12 Jun 2010 12:00:06 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs Date: Sat, 12 Jun 2010 16:58:58 +0100 References: <201006121515.17695.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006121658.58928.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 > I think message passing interrupts > are only used in bus based systems, like PCI or UPA/JBUS etc. I don't > know how LAPIC/IOAPIC bus works, it could be similar. PCI Message Signalled Interrupts use a regular data write, and we model it exactly that way. Under normal circumstances you program the device to write to memory mapped APIC control registers, but there's no real reason why you couldn't write to RAM. LAPIC/IOAPIC have their own bus. On some hardware this is multiplexed over the main system bus, but logically it is a separate interconnect. The fact that these a bus based systems suggests against using qemu_irq, which is an inherently point-point system. > > How is a > > receiver meant to know for format of the message being delivered, and who > > it's intended for? > > This depends on the architecture. On Sparc64 the message is specified > by the guest or OF. >... > In real HW (MSI or Sparc64 mondo interrupts) a bus delivers the > message. But our buses only handle address and data lines. IIUC you're trying to use qemu_irq as a generic interconnect between devices. I think that's going to cause more problems than it solves. If a bus has additional message passing capabilities then this can be part of the bus interface. If two devices need a private communication channel then we probably want some implementation agnostic way of defining this link. Connecting LAPIC to IOAPIC is a potential example of this. However this needs to be done in a type-safe manner. DMA channels may be another potential use of this linking. We'd want to avoid connecting a DMA channel to an APIC. [*] 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. > > TBH I preferred the original system whereby the source can query the > > state of the sink (i.e "are you ignoring this line?"). Note that > > conceptually this should be querying state, not responding to an event. > > It's simple, but I think too simple. It would work for the coalescing > interrupt hack but useless for other things. I'm not convinced making qemu_irq do "other things" is a good idea. Paul