From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=57217 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1ONpRt-0002oD-VO
	for qemu-devel@nongnu.org; Sun, 13 Jun 2010 11:50:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1ONpRs-0007ol-NQ
	for qemu-devel@nongnu.org; Sun, 13 Jun 2010 11:50:13 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:58889)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1ONpRs-0007oU-Bb
	for qemu-devel@nongnu.org; Sun, 13 Jun 2010 11:50:12 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
Date: Sun, 13 Jun 2010 16:49:02 +0100
References: <cover.1275811861.git.jan.kiszka@web.de>
	<AANLkTilhCLANjs6dTH3gu_M_l-haeU2jWr7Jxy1igJtZ@mail.gmail.com>
	<AANLkTim9u85rRcRXKn0DS-sZEoJSIOa4WJq4Xlo2eaLF@mail.gmail.com>
In-Reply-To: <AANLkTim9u85rRcRXKn0DS-sZEoJSIOa4WJq4Xlo2eaLF@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201006131649.02519.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Jan Kiszka <jan.kiszka@web.de>, qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>, Juan Quintela <quintela@redhat.com>

> I think we could solve all problems (well, maybe not world peace, yet)
> by switching to message based system for all of DMA and IRQs.
> 
> Each device would have a message input port and way to output messages.
> 
> Examples:
> 
> Zero copy memory access from device D1 to D2 to host memory (D3) with
> access broken to page length units and errors occurring on the last
> byte:
> D1 send_msg(ID, MSG_MEM_WRITE, DMA address, length) -> D2
>...
> IRQ delivery chain D1->D2->D3 with coalescing, messages, delivery
> reporting and EOI:
> D1 send_msg(ID, MSG_IRQ_RAISE, payload) -> D2

This feels like a terrible idea to me. It introduces an unnecessary RPC 
indirection layer without actually solving any of the problems. It just makes 
it harder (if not impossible) for the compiler to verify any of the interfaces 
between objects.

If we need a mechanism for a device to query the state of its outgoing IRQ 
lines (which is what I mentioned previously), then we can just add that. I 
still maintain that qemu_irq is *not* a message passing interface, and that 
this absence is a good thing. Maybe if I make the qemu_irq code actively 
suppress redundant level change notices that would make things clearer.

Paul