From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUids-00079D-Gz for qemu-devel@nongnu.org; Thu, 09 Jun 2011 13:03:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QUidq-0000pi-Ir for qemu-devel@nongnu.org; Thu, 09 Jun 2011 13:03:36 -0400 Received: from goliath.siemens.de ([192.35.17.28]:18937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUidq-0000p5-72 for qemu-devel@nongnu.org; Thu, 09 Jun 2011 13:03:34 -0400 Message-ID: <4DF0FCDA.5070804@siemens.com> Date: Thu, 09 Jun 2011 19:03:22 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1307532813-27175-1-git-send-email-peter.maydell@linaro.org> <4DEF6B2B.7090305@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , Anthony Liguori , =?ISO-8859-1?Q?Juha_Riihim=E4ki?= , "patches@linaro.org" , "qemu-devel@nongnu.org" , Paul Brook On 2011-06-09 18:40, Markus Armbruster wrote: > Jan Kiszka writes: > >> On 2011-06-08 13:33, Peter Maydell wrote: >>> At the moment you can't really implement one sysbus device by saying >>> that it's composed of a set of other sysbus devices. This patch adds >>> new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which >>> allow a sysbus device to delegate an MMIO or IRQ to another sysbus >>> device (The approach is inspired by the existing sysbus_pass_irq() >>> which lets a sysbus device delegate all its IRQs at once). >>> >>> This works; the most obvious deficiency is that the subcomponent >>> device will still appear as its own device on the bus. >>> >>> So: is this a reasonable solution to the problem, or an unacceptable >>> hack? Comments welcome :-) >> >> Sounds more like a little hack. :) >> >> The relationships should be expressed via qdev, not yet another >> sysbus-specific extension. Generally, many services of sysbus should >> rather be generic qdev things. > > Examples? Resource management, e.g. IRQs. That will be useful for other types of buses as well. > >> Is there anything that today prevents creating a local bus and attaching >> the component devices to that? If it's multi-bus support, that should to >> be added anyway. Passing-through of MMIO and IRQs is still a worthwhile >> generic service, then probably qbus associated. > > Do you mean making the container device a sysbus-sysbus-bridge, then > hanging the component devices off the inner sysbus? And how to apply this concept on a composed PCI device e.g.? Maybe we could define something like Linux' struct resource + a set of helper services for it. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux